LINUX.ORG.RU

История изменений

Исправление Camel, (текущая версия) :

Т.е. теперь мне нужно не только писать и поддерживать юнит-тесты, но и Cucumber тоже?

Да, конечно. Потому что эти инструменты тестируют совершенно разные вещи. Если заказчик в требованиях пишет «хочу программу, чтобы я в неё загружал заказы, а она мне в ответ выдавала маршрутные листы для курьеров», то на Gherkin'е вы напишите:

Если я загружаю заказы
То получаю маршрутные листы
А в программе у вас будут классы ЗагружательЗаказов, ВычисляторМаршрутов и ВыгружательМаршрутныхЛистов, для которых вы напишите соответствующие модульные тесты. А может быть у вас будут другие классы и другие тесты. Но модульные тесты останутся на уровне классов и модулей, а приёмочные на уровне требований заказчика.

Дополнение: крайне полезно вовлекать заказчика в работу с Gherkin'ом. Если не в форме сочинительства и редактирования, то хотя бы утверждения. Когда требования более запутанные, когда тестируемые сценарии более сложные, лучше если заказчик убедится, что тестируется именно то поведение которое ему в итоге нужно, что в сценариях описываются шаги именно в той последовательности которую представляет заказчик.

Исходная версия Camel, :

Тестирование разных вещей

Т.е. теперь мне нужно не только писать и поддерживать юнит-тесты, но и Cucumber тоже?

Да, конечно. Потому что эти инструменты тестируют совершенно разные вещи. Если заказчик в требованиях пишет «хочу программу, чтобы я в неё загружал заказы, а она мне в ответ выдавала маршрутные листы для курьеров», то на Gherkin'е вы напишите:

Если я загружаю заказы
То получаю маршрутные листы
А в программе у вас будут классы ЗагружательЗаказов, ВычисляторМаршрутов и ВыгружательМаршрутныхЛистов, для которых вы напишите соответствующие модульные тесты. А может быть у вас будут другие классы и другие тесты. Но модульные тесты останутся на уровне классов и модулей, а приёмочные на уровне требований заказчика.