Практическая реализация методики BDD

В предыдущей заметке были рассмотрены ограничения применения BDD. Опишу свое видение использования методологии BDD с такими основными этапами:

1. разработка спецификации требований;
2. разработка высокоуровневых сценариев;
3. разработка детальных сценариев;
4. разработка функционала вместе с автотестами.

1. Разработка спецификации требований

Требования фиксируются и согласовываются с заказчиком в привычном для него виде.

2. Разработка высокоуровневых сценариев

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

Совмещая п.п. 1 и 2, можно выявить пропущенные требования или противоречия в требованиях. Тем самым обеспечить полноту и непротиворечивость собранных требований.

3. Разработка детальных сценариев

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

Для получения сценариев в едином виде необходима автоматизированная система, которая позволит вести разработку сценариев с использованием единых тестовых данных. Далее сценарии автоматически преобразовываются в программный код автотестов.

4. Разработка функционала вместе с автотестами

Выполняется разработка системы. Команда разработчиков создает функционал системы и функционал автотестов по сценариям, разработанным на предыдущем этапе. Цикл разработки выполняется согласно подходу: Red-Green-Refactoring. Автотесты встраиваются в систему непрерывной интеграции.

Вывод

Для поддержки этого процесса нужна автоматизированная система, которая должна позволять следующее:

• Связать требования с пользовательским сценарием - многие ко многим;
• Связать пользовательский сценарий с детальными сценарием - один ко многим;
• Преобразовать тестового сценария в исполняемый код автотеста.

Данный подход все равно обладает существенным ограничением, заказчик полностью выключен из творческого процесса создания продукта. На команду ложится груз работы по поддержке 2х параллельных процессов. Чем более формальный заказчик, тем меньше возможности уделять достаточно времени подходу BDD.