Как язык программирования и среда разработки влияют на TDD?
Попробуйте использовать подход TDD в среде Smalltalk с браузером Refactoring Browser. Теперь попробуйте работать в среде C++ с редактором vi. Почувствуйте разницу.
В языках программирования и средах разработки, в которых цикл TDD выполняется сложнее (тест – компиляция – запуск – рефакторинг), возникает тенденция двигаться вперед более длинными шагами:
• каждый тест охватывает больший объем кода;
• рефакторинг выполняется с меньшим количеством промежуточных шагов.
Приводит ли это к замедлению разработки, или, наоборот, разработка ускоряется?
В языках программирования и средах, в которых проще выполнить цикл TDD, у вас будет возникать желание больше экспериментировать с кодом. Позволит ли это двигаться быстрее и формировать лучшие решения, или вам кажется, что лучше тратить время на дополнительные размышления о дизайне?
Можно ли использовать TDD для разработки крупномасштабных систем?
Позволяет ли методика TDD разрабатывать крупномасштабные программные проекты? Какие новые типы тестов вам потребуется написать? Какие новые шаблоны рефакторинга могут потребоваться?
Самой крупной программной системой, целиком и полностью разработанной в стиле TDD, в создании которой я принимал участие, является система LifeWare (www.lifeware.ch). Работа над системой велась в течение 4 лет. Объем работ оценивается в 40 человеко-лет. На текущий момент система включает в себя 250 000 строк функционального и 250 000 строк тестирующего кода (на языке Smalltalk). Набор тестов системы включает в себя 4000 тестов, для выполнения которых требуется 20 минут. Полный набор тестов запускается несколько раз каждый день. Реализованный в системе огромный объем функциональности, похоже, никак не снижает эффективности TDD. Избавляясь от дублирования, вы стараетесь создать большое количество маленьких объектов, которые можно тестировать изолированно друг от друга вне зависимости от размера приложения.
Можно ли осуществлять разработку через тестирование на уровне приложения?
Если мы будем выполнять разработку, используя только внутренние программистские тесты (их называют тестами модулей – unit tests, – хотя они не вполне соответствуют этому определению), мы рискуем столкнуться с проблемой: полученная в результате этого система может оказаться не совсем тем или, что хуже, совсем не тем, что хочет получить пользователь. Программист будет работать над программой, которая,
