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