"Непотопляемый" приемочный тест

Автор: Александр Якима

На прошлом воркшопе, посвященном Разработке Через Приемочные Тесты (ATDD) (http://www.enter-agile.com/2011/11/workshop-atdd-with-junit.html) прозвучал вопрос о том, как быть с приемочным тестом, идея которого пришла уже после написания самой функциональности и, более того, мы практически уверены, что тест успешно выполнится. Суть вопроса в том, нужен ли вообще такой тест, который, кстати, даже не удастся "завалить"?

Вот некоторые аспекты такой ситуации, которые важно учитывать:
  • Да, тест который мы так и не видим не выполняющимся, опасен, так как в нем самом может быть ошибка. Однако, как всегда в таких случаях, ошибка просто имеет свою вероятность, и более того, есть шансы, что в будущем она выявится. То есть, мы точно ничего не теряем.
  • Во-вторых, тест вполне вероятно будет все же корректным и через некоторое время при изменении покрываемой им функциональности может отловить свежепоявившуюся проблему в коде. Ценность очевидна.
  • И, наконец, тест часто можно целенаправлено завалить, даже если кажется, что это уже невозможно. Смотрим, какие еще два-три полезных теста мы могли бы реализовать, чтобы более точно описать поведение этой функциональности. Запускаем и сваливаем их. Начинаем работать над реализацией под эти тесты. Есть неплохие шансы, что запуская тесты в процессе такой работы мы завалим наш основной тест и цель будет достигнута.

Не будем также забывать, что речь идет о приемочных тестах, которые обычно определяются командой совместно с заказчиком (в идеальном случае), или хотя бы командой, но не индивидуально отдельно взятым разработчиком. А это значит, что перед имплементацией у нас уже быдет целый набор "примеров" поведения системы, которые мы и реализуем в качестве тестов вначале, а потом добавим реализацию. Таким образом мы сможем увидеть все тесты незапускающимися в какой-то момент времени.

Наконец, отметим, что хоть "примеры" и разрабатываются всей командой, очень важно продолжать в таклм же духе сотрудничества и на этапе написания самих тест-скриптов. Неплохо помогает работать над созданием тестов в паре. Тогда значительно легче сразу же отловить ошибки в самих тестах.

No comments:

Post a Comment

 
Powered by Blogger