comments powered by DisqusВсем привет,
я получил кое-какие результаты, эти результаты показывают что стоимость написания приемочных тестов высока и дело тут не в самом BDD и Cucumber, а в том как у нас устроен код и в том что уже слишком много кода написано.
Сначала о хорошем. Сценарий приемочного теста может быть легко написан тестировщиком, легко читается всеми участниками проекта, документирует фичу и легко автоматизируется при определенных условиях (у нас они не выполняются).
Теперь о том почему стоимость имплементации таких сценариев высокая. Сценарий требует управления данными над которыми он выполняется. Если данные можно подготовить заранее, то это можно сделать с помощью SQL скрипта, но это довольно трудоемко (потому что у нас по сути все данные табличные и доменная модель почти целиком участвует в большинстве сценариев). Если данные должны меняться во время работы сценария, то ими надо управлять из теста, а это требует разработки слоя поддержки доменной модели (также такой слой был бы удобнее SQL скриптов для создания первоначальных данных), которого у нас нет (то есть код который будет позволять создавать объекты доменной модели в рантайме).
Следующая проблема - это то что у нас используется native-sql. Для таких случаев надо писать код поддержки для тестов. Например, функция UNIX_TIMESTAMP (datetime) отсутствует в H2 (в H2 разворачивается база для тестов), а мы ее используем.
Следующая трудность - сервисов много, контроллеров много, dao много. Надо понимать что мокать, что не мокать, а это время.
Следующая трудность - это то что у нас большая часть функциональности зависит от вызова now(). Такие части трудно тестировать. Другими словами есть куски кода, которые требуют рефакторинга, чтобы сделать код тестабельным.
В общем, чтобы Cucumber приносил пользу нужно чтобы выполнились два условия:
- Каждая фича формулируется как Cucumber-сценарий
- Разработка идет от сценария, а не наоборот. То есть пишем код который покрывает сценарий все больше и больше с каждой итерацией, а не наоборот когда пишется код, а потом сценарий.
- Нужен фреймворк поддержки тестов, который позволил бы легко и удобно и без ошибок создавать исходные данные (доменные объекты) для тестов и манипулировать ими в рантайме. (это большая задача)
Покрывать текущую функциональность Cucumber-сценариями дорого, уже много сделано (система давно в PRODе) и написать ко всему тесты это очень много времени.
Получается что либо мы оставляем все как есть и продолжаем писать локальные юнит тесты, либо мы меняем подход к разработке и переходим на BDD. Но в последнем случае нам потребуется не только перестроить подход к написанию кода и проработке фич, но и проделать работу по созданию программной инфраструктуры, которая позволила бы перейти на BDD.
