Некоторые вырезки по BDD из книги от создателей Cucumber

gistfile1.txt

- Каждый сценарий должен иметь смысл и выполняться независимо от других сценариев. Это подразумевает что каждый сценарий должен иметь достаточно шагов Given для того чтобы создать необходимый контекст для выполнения теста.

- Создатели фич должны иметь возможность описать свои мысли в свободной форме, чтобы фича читалась натурально. Это означает что они могут использовать фразы отличающиеся друг от друга но подразумевающие один результат. Очень важно чтобы фичи не звучали как написанные роботом. 

- При написании фич, сделайте упор на читабельность, в противном случае они будут выглядеть как программа или тех спецификация и мы хотим избежать этого любой ценой! Ведь если не программист с трудом может понять что происходит в фиче, зачем тогда вообще их писать? ( Ведь ВDD в первую очередь направлен на коммуникацию - если это отбросить то можно вернуть к старым добрым simpletest или codeception )

- Старайтесь избегать технических деталей вроде "чистка очереди", "запуск back-end сервиса", "открытие браузреа на бекграунде". Большинство этих деталей будут подразумеваться, поэтому просто реализуйте их в application driver.

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

- При использовнии секции примеров ( Examples ) не забудьте включить небольшое описание для каждого из них. Очень многие забывают это сделать.

Examples: Успешное снятие средств
|Баланс|Сумма|Результат|Остаток|
........

Examples: Попытка снять слишком много
|Баланс|Сумма|Результат|Остаток|
........

Плохой пример

Examples:
|Password|Valid or invlid|
........

Хороший

Examples: Слишком короткий пароль
  Пароли менее 4 символов не верны

|Password|Valid or invlid|
........

- Старайтесь избегать вложенных шагов ( когда один вызывает другой ). Правильный способ использовать ADL.

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

Типичный пример слишком узко заточенного сценария:

Сценарий: Направить пользователя на страницу которую он запрашивал изначально после входа в систему.

Имея пользователя "Дейв" с паролем "секрет"
И я не авторизирован
Когда я перехожу на главную страницу
Тогда меня перенаправляют на форму входа
Когда я заполняю поле "username" значением "Дейв"
И поле "password" значением "секрет"
И нажимаю кнопку "Войти"
Тогда я должен оказаться на главной странице

Вот этот же сценарий, более абстрагированный от имплементации:

Сценарий: Направить пользователя на страницу которую он запрашивал изначально после входа в систему.

Имея анонимного пользователя
Когда пытаюсь посмотреть какой нибудь запрещенный контент
Тогда мне показывается форма входа
Когда я ввожу правильные данные
Тогда я должен увидеть этот запрещенный контент

- Старайтесь спрятать всю конкретику реализации сценария в ADL ( application driver layer )

- Еще раз повторюсь - все сценарии должны быть независимы друг от друга.

- Избегайте использование Fixtures любой ценой, мы считаем их antipatternom. Как показывает практика fixtures превращаются в огромную монолитную массу, к торой очень тяжело разбираться. Так же это создает проблемы на фазе инициализации теста ( со временем медленно и тяжело чистить). Это в свою очередь подталкивает разработчиков к попыткам не чистить мусор после прогона сценариев, что приводе к большой мешанине.

- Команды которые с энтузиазмом берутся за BDD ( Cucumber или Behat ) частенько забывают писать обычные unit tests и полагаются вместо них на более медленные интеграционные тесты. Старайтесь думать о ваших Behat сценариях как о чем то более обобщенном, как мазки краски которые обрисовывают общую структуру системы. В тоже время большинство функционала должно иметь гораздо более быстрые unit тесты!

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

- С ростом количества сценариев, частенько возникает задача прогнать только определенные сценарии ( а остальные на Integration Server ). Для этого используйте теги. Частая практика временно помечать сценарии или фичи уникальным тегом и затем прогонять только их.

- Старайтесь избегать большого числа не доделанных фич либо сценариев. Постарайтесь внести в привычку, что каждый сценарий или фича над которыми ведется работа должен быть помечен тегом ( например @wip - work in progress ). По завершению работы этот тег убирается. Благодаря этому можно быстро получить список фич в работе и даже контролировать превышение определенного числа.