До последнего времени юнит тесты писал избирательно — для логики с нетривиальными алгоритмами, чтобы сразу отлавливать ошибки и т.п.
Сейчас на одном небольшом проекте заказчик попросил работать по TDD — т.е. сначала пишем тесты, потом сам тестируемый код (хотя оговорил, что надо это делать не всегда, а только когда требуется, т.к. иначе будет слишком медленно).
Сама по себе идея тестировать весь код и строить архитектуру соответствующим образом мне стала очень близка, но столкнулся со следующей проблемой:
Мне комфортно придумывать мелкую архитектуру на лету. Т.е. я пишу серию взаимосвязанных классов, делаю какой-то набор методов, смотрю на это все, если мне не нравится, тут же переделываю с использованием инструментов рефакторинга (Java, Eclipse). Если нужно написать реализацию какого-то сложного алгоритма, зачастую мне удобнее сперва написать длинный метод, затем разделить его на более мелкие, чтобы красиво читалось.
Так вот: По TDD требуется писать тест до реализации, но у меня еще нет представления, какие методы, какие классы будут, я могу их пять раз переименовать, перегруппировать. При этом каждый раз надо переделывать тесты. Получается слишком трудоемко. Выходит, что мне удобнее сперва определиться с реализацией, набором классов, методов, а потом только делать код, который это тестирует.
