Test-driven development (TDD) — разработка через тестирование (это уже не hope-driven development), процесс разработки программного обеспечения, основанный на коротких циклах разработки: написании специфичных тестов, затем процессу разработки до такого уровня, чтобы успешно проходили тесты, написанные на предыдущем этапе.
Я ещё ни разу не видел чистой разработки через тестирование. Обычно во время разработки спецификация будущей программы постоянно меняется и дополняется, даже если были каким-то образом описаны тесты, то описание этих тестов подстраивается под то, что в конечном итоге должно получиться
Сложно представить на столько идеальную среду, чтобы первоначально можно бы было идеально описать тесты, а затем заниматься их реализацией. Если кому-то удалось, то отпишитесь в комментариях, пожалуйста. Я же пока видел ситуации, когда были попытки написания тестов, но в последствии при разработке изначально придуманные интерфейсы приходилось подстраивать под внезапно возникшие потребности либо самого бизнеса, либо получающейся архитектуры программного обеспечения. Могу лишь предположить, что к этому нужно стремиться, но нужно ли?
Test-driven development обычно состоит из циклично повторяющейся последовательности шагов:
1) добавить тест;
2) запустить все тесты и убедиться, что новый тест не проходит;
3) Написать код;
4) Запустить все тесты и убедиться, что все тесты проходят;
5) Рефакторинг кода для улучшения;
6) Повторить цикл снова.
Преимущества разработки через тестирование:
- уменьшение количества багов;
- архитектура приложения больше подходит для тестирования, так как тесты пишутся сначала;
- поскольку пишется лишь тот код, который необходим для прохождения теста, то автоматизированные тесты покрывают все пути исполнения;
Часто встречающиеся подводные камни:
- разработчики могут забывать запускать тесты;
- написание слишком большого количества тестов за один проход;
- только часть команды использует TDD;
Недостатки test-driven development:
- некоторые задачи невозможно решить при помощи тестов;
- накладные расходы на написание тестов;
- уровень покрытия тестами, который был получен в результате TDD, сложно получить впоследствии
- требуется больше времени на разработку и поддержку.
Вывод:
На мой взгляд чистый test-driven development в современной разработке корпоративного программного обеспечения смахивает на утопию. Тесты нужны, никто не спорит, но современные системы учёта и разработки программного обеспечения достаточно сложны, поэтому писать только тот код, который необходим для выполнения конкретного теста, не всегда представляется возможным. Кто видел чистый TDD в Java и Spring отзовитесь! Однако при реализации какой-нибудь библиотеки разработка через тестирование может дать вполне отличный результат, я думаю.