Рекомендации по ведению BDD (Behavior Driven Development)

Введение в BDD

BDD (Behavior Driven Development) - это методология разработки программного обеспечения посредством непрерывной связи между разработчиками, QA и BAS. В этой статье мы обсудим некоторые примеры BDD для получения максимальной выгоды. Эффективный тестировщик очень ценен на рынке труда, поэтому стать успешным в этой сфере Вам помогут наши курсы тестировщиков.

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

В BDD примеры называются сценариями. Сценарии структурированы по шаблону «Контекст-Действие-Результат» и написаны в специальном формате «Gherkin». Сценарии - это способ объяснить (на простом английском), как данная функция должна вести себя в разных ситуациях или с разными входными данными.

Что такое файл функции и что он содержит?

Файлы функций представляют собой текстовые файлы с расширением .feature, которые могут быть открыты любым текстовым редактором, а также доступны для чтения любым инструментом, поддерживающим BDD, например, Cucumber, JBehave или Behat.

Файлы функций должны начинаться с контекста функции (которая по существу является историей), за которой следует по меньшей мере один сценарий в следующем формате.

Особенность: некоторый краткий, но описательный текст ожиданий от разработки

Для реализации названной бизнес-цели:
  • Я хочу получить положительный результат, который будет способствовать достижению цели

Сценарии в файлах должны фокусироваться на «что», а не «как». Сценарии должны быть краткими и точными, чтобы читатель мог быстро понять цель теста, не читая много шагов.

Зачем нам писать файлы функций?

Как упоминалось ранее, основной целью методологии BDD является поощрение коммуникации между членами команды. Цель файлов с характеристиками - документировать сценарии, о которых говорилось, чтобы дать представление о том, как много работы связано с разработкой какой-то конкретной функции. Файлы функций также являются драйверами для автоматизированных тестов. Файлы функций также служат определением Готово (DoD), а это значит, что когда все сценарии были реализованы и успешно протестированы, мы можем отметить историю как выполненную.

Кто должен писать файлы функций?

На самом деле не имеет значения, кто на самом деле записывает / печатает файлы функций, это может быть любой член команды, однако содержимое (сценарии), которое обсуждается трио Dev-QA-BA, является неотъемлемой частью процесса. Получение общего понимания этой функции является ключевым элементом.

Когда должны быть написаны файлы функций?

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

Где должны храниться файлы функций?

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

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

Как нам написать файлы функций?

Обычно существуют два способа написания файлов функций - императивный и декларативный

Императивный стиль написания файла функции содержит детали и слишком много информации.

Плюсы: человек, читающий файл функции, может следовать шаг за шагом

Минусы: из-за слишком большой детализации, читатель может потерять смысл истории и тестов. Файл функции становится слишком большим, его трудно поддерживать и, скорее всего, не удастся использовать из-за обновлений пользовательского интерфейса.

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

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