Ситуация: миллионы строк кода, более сотни разработчиков и частые дефекты. Мы хотим избежать повторения дефектов, и мы хотим улучшить дизайн кода (кто нет?).
Test Driven Development (первый unit test, затем код) звучит идеально: напишите тестовый пример для каждой функции.
Но, с таким количеством написанного кода, как TDD может быть реализован? С чего начать - с функциями низкого уровня?
Или мы слишком поздно запускаем TDD?
Начните с Эффективно работайте с устаревшим кодом.
Это не TDD, если вы начинаете с устаревшего кода, но все ваши кодировки могут быть TDD. Когда вы решаете новую проблему, напишите для нее тест. Если вы не можете, потому что устаревшие классы слишком сложны для тестирования, тогда начните писать тесты для них, вырезать биты и покрывать биты тестами.
Реорганизовать низко висящие фрукты.
Чтобы избежать повторения дефектов: с учетом примера дефекта, напишите тест, который его демонстрирует. Это может быть относительно широкий тест, который просто имитирует активность пользователя; еще не unit test. Убедитесь, что тест завершился неудачно. Сделайте свое исследование; выяснить, почему тест терпит неудачу. Теперь - это важно - прежде чем исправлять ошибку, напишите unit test, который демонстрирует ошибку. Исправьте ошибку, и теперь у вас есть два теста, по крайней мере один из них быстро, которые защищают вас от регрессий.
Так как Карл предложил одну книгу, я предлагаю другую: Roy Osherove Искусство модульного тестирования содержит целую главу "Работа с устаревшим кодом". Я еще не читал эту главу, но первые 5 глав превосходны, и я с нетерпением жду этого.