Test-Driven Development

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 отзовитесь! Однако при реализации какой-нибудь библиотеки разработка через тестирование может дать вполне отличный результат, я думаю.


Поделиться:
1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (Пока оценок нет)
Загрузка...

Добавить комментарий

Ваш e-mail не будет опубликован.