Пишите тесты. Обязательно пишите. Это поможет вам чувствовать уверенность в завтрашнем дне. Чтобы быть уверенным в том, что код и вся архитектура не развалится завтра при случайной правке базового класса или внесении правок в ТЗ.
Пишите тесты к:
1. Пользовательским сценариям (UseCase) из ТЗ.
2. Пунктам детализирующим ТЗ. Такие тесты позволят кроме проверки пунктов ТЗ ещё и находить противоречия в ТЗ.
3. Найденным ошибкам. (!)
4. Стабильно повторяющимся ошибкам. (!!)
5. Ошибкам, которые "вернулись уже не раз". (!!!)
6. Атомарные тесты к базовым классам. Типа: List.Add(10); Check(List[0] = 10); Такие тесты помогут вам при переходе с одной платформы на другую.
7. Unit-тесты к самым базовым классам.
8. Тесты, которые помогают "быстро влиться в разработку" пока несуществующего проекта. Такие тесты позволят вам "не ждать коллег".
9. Ошибкам стандартных библиотек, которые вы поправили. Эти тесты помогут вам проще переходить на новые версии этих библиотек.
10. К нестандартным решениям и "копанию в кишочках" своего и чужого кода.
11. Отдельно к различным преобразованиям из одного формата в другой. Такие тесты легко пишутся через mock'и или эталонные файлы. Конечно их надо иметь достаточный набор.
12. Если вы что-то долго и нудно оптимизируете по памяти и/или быстродействию. Пишите тест. Он поможет вам уследить за ситуацией, когда оптимизация вышла за желаемые рамки.
13. Граничным условиям и неверному пользовательскому вводу.
14. Если у вас с коллегами возникли разногласия о поведении системы на "границе сфер влияния".
15. Коду других коллег, которые уже не с вами. Особенно когда он вызвал вопросы типа - "а что это такое", "а может быть тут внести такую правку".
По моим наблюдениям за последние несколько лет - тестов, в "идеальном случае", пишется не меньше, а порой и больше, чем "реального кода". Но они влияют друг на друга. Возникает некий синергетический эффект, когда код влияет на тесты, а тесты влияют на код. А зачастую и тесты ведут к улучшению архитектуры системы с целом.
Одно только введение "контрольных точек" позволяет оценить систему не с точки зрения "монолита", а с точки зрения "а что бы было бы" если бы вот тут можно было бы снять показания или внести запланированные помехи.
Насчёт "тесты замедляют процесс разработки" - прокомментирую лишь в таком ключе - у меня - не замедляют, даже иногда и ускоряют (см. например пункт 8). Но при этом тесты дают гораздо большую свободу манёвра. Я безбоязненно правлю самые базовые классы и код коллег, которых со мною уже рядом нет. Я всегда знаю, что я могу прогнать набор тестов и посмотреть - "а что же будет". И мне приходится гораздо меньше сомневаться - стоит вносить ту или иную правку в проектный код или нет.
Попробуйте. Может быть вам понравится.
Update. Опять же читаем статью -
http://delphi.frantic.im/delphi-tdd/ и КОММЕНТАРИИ к ней.
