Не могу не подчеркнуть достоинства метода разработки на основе TDD. Когда вы принимаете TDD, ваши юнит-тесты становятся первоклассными гражданами наряду с написанным вами кодом, а не кодом, который поддерживается ради проведения юнит-тестов и не поддерживается в актуальном состоянии.
В TDD вы используете свои юнит-тесты как исполняемую спецификацию того, что должен делать ваш компонент. Это можно сделать, подумав, что должен делать ваш компонент, а затем написав тесты для реализации этой функциональности. Поскольку ваш код изначально не будет обладать какой-либо из этих функций, все новые тесты, которые вы пишете, будут неудачными или будут красными. Как только вы получите свои тесты, начните реализацию компонента. Постепенно, по мере добавления требуемой функциональности, красные тесты станут зелеными. Приятно то, что после того, как вы реализовали достаточно функциональности, чтобы пройти все свои тесты, вы знаете, что завершили реализацию намеченной спецификации и точно знаете, где остановиться. Слишком часто я сталкивался с ситуациями, когда разработчик заканчивал реализацию требуемой функциональности, но не останавливался, вместо этого улучшая компонент и добавляя дополнительную функциональность и привлекательность, ни одна из которых не является частью необходимой спецификации, тратя время на активную разработку ,
После проведения юнит-тестов это легко настроить в среде непрерывной интеграции. Эта среда будет извлекать последний код из вашего репозитория, собирать его, а затем запускать ваши юнит-тесты. Если произойдет какая-либо регрессия, если кто-нибудь проверит какой-либо код, который нарушает ваши юнит-тесты, вы узнаете об этом сразу, а не узнаете после того, как он будет развернут в вашей производственной среде. Чтобы гарантировать, что новый код не вводит регрессию, мы настроили хуки входа в систему в нашем репозитории, чтобы гарантировать, что для всего представленного кода также выполнялись сопровождающие тесты и что они прошли. Это особенно полезно, когда над проектом работают несколько человек, так как они могут видеть через любую панель мониторинга, которую вы можете использовать, хорошо ли синхронизируется репозиторий в данный момент времени или нет. Также легко локализовать определенную версию репозитория, которая работает, позволяя людям работать с хорошо известными версиями, в то время как кто-то еще работает над исправлением любой проблемы, которая в настоящее время нарушает вашу сборку. Это также может означать, что любая «зеленая» сборка, указанная на информационной панели, является сборкой, которая с очень высокой вероятностью не столкнется с проблемами при передаче в производственную среду.
Многие люди думают, что принятие TDD будет означать дополнительную работу и хлопоты, и что это займет больше времени. Учтите, однако, что дополнительное время, потраченное на написание тестов, предотвратит взлом любой тестируемой функциональности, и вы найдете эти перерывы раньше, чем позже.
Еще одним преимуществом использования TDD является то, что вы будете уделять своему дизайну гораздо больше внимания, и что он будет намного лучше структурирован и составлен по сравнению с подходом без TDD. Эта компонентность важна для возможности иметь набор модульных тестов, который быстро выполняется и не является хрупким.
GUI-тестирование сложно, но не невозможно. Рассмотрим технологии тестирования веб-интерфейса, такие как Selenium, WebDriver и Watir, которые могут программно использовать веб-интерфейс. Этими инструментами тоже легко злоупотреблять, выполняя только дорогостоящее сквозное тестирование с их использованием. Гораздо лучший подход - абстрагировать ваш уровень пользовательского интерфейса, чтобы он мог тестироваться изолированно, независимо от вашей бизнес-логики. Вы не хотите, чтобы тестирование пользовательского интерфейса выполнялось и выполняло операции с базой данных.
Чтобы подытожить, вы хотите написать эффективные модульные тесты, чтобы сделать использование TDD приятным, а не обременительным процессом. Ваши тесты должны быть быстрыми, тестировать компоненты изолированно и в идеале запускаться постоянно.
То, что я здесь описал, является идеальным случаем. Вам не нужно принимать каждую упомянутую идею, но вы можете выбирать все, что работает, чтобы сделать процесс разработки более эффективным.