Разработка, управляемая поведением - Краткое руководство

Разработка, управляемая поведением (BDD) - это процесс разработки программного обеспечения, изначально возникший из разработки, управляемой тестированием (TDD).

По словам Дэна Норта, ответственного за развитие BDD, «BDD использует примеры на нескольких уровнях, чтобы создать общее понимание и поверхностную неопределенность для предоставления программного обеспечения, которое имеет значение».

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

Конвертируется в исполняемые спецификации.
Используется в качестве приемочных испытаний.

BDD - Ключевые особенности

Разработка, управляемая поведением, фокусируется на -

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

Происхождение BDD

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

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

Потребность часа - это подход к развитию, который:

Основано на требованиях.
Ориентирован на требования на протяжении всей разработки.
Обеспечивает выполнение требований.

Подход к разработке, который может удовлетворить вышеупомянутые требования, - это BDD. Таким образом, разработка, управляемая поведением -

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

Практика BDD

Две основные практики BDD:

Спецификация на примере (SbE)
Разработка через тестирование (TDD)

Спецификация на примере

Спецификация на примере (SbE) использует примеры в разговорах, чтобы проиллюстрировать бизнес-правила и поведение создаваемого программного обеспечения.

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

Разработка через тестирование

Разработка через тестирование в контексте BDD превращает примеры в удобочитаемые, исполняемые спецификации.

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

Гибкий BDD

В Agile-разработке программного обеспечения метод BDD используется для достижения общего понимания ожидаемых спецификаций.

Следующие шаги выполняются в Agile BDD -

Разработчики и владелец продукта совместно пишут ожидающие рассмотрения спецификации в текстовом редакторе.
Владелец продукта указывает поведение, которое они ожидают от системы.
Разработчики
- Заполните спецификации этими деталями поведения.
- Задавайте вопросы, исходя из их понимания системы.
Рассматривается текущее поведение системы, чтобы увидеть, нарушит ли новая функция какие-либо из существующих.

Agile Manifesto и BDD

В Agile Manifesto говорится следующее:

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

Individuals and interactions - над Процессами и инструментами
Working software - Более подробная документация
Customer collaboration - по переговорам по контракту
Responding to change - более Следуя плану

То есть, хотя предметы справа имеют ценность, мы больше ценим предметы слева.

BDD присоединяется к манифесту Agile следующим образом:

Agile Manifesto	Выравнивание BDD
Люди и взаимодействие важнее процессов и инструментов.	BDD - это разговоры.
Рабочее программное обеспечение требует исчерпывающей документации.	BDD делает упор на создание программного обеспечения, имеющего ценность для бизнеса.
Сотрудничество с клиентами вместо переговоров по контракту.	BDD фокусируется на сценариях, основанных на идеях, при постоянном общении с заказчиком по мере развития. Он не основан ни на каких обещаниях.
Реагирование на изменения вместо следования плану.	BDD фокусируется на непрерывном общении и сотрудничестве, которое способствует принятию изменений.

Когда вы посмотрите любую ссылку на разработку, управляемую поведением, вы обнаружите, что используются такие фразы, как «BDD происходит от TDD», «BDD и TDD». Чтобы узнать, как появился BDD, почему он считается производным от TDD и что такое BDD и TDD, вы должны понимать TDD.

Почему именно тестирование?

Для начала давайте познакомимся с основами тестирования. Цель тестирования - убедиться, что созданная система работает должным образом. Рассмотрим следующий пример.

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

Этот подход к тестированию называется подходом Test-Last, поскольку тестирование выполняется после завершения этапа.

Проблемы с подходом Test-Last

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

Задержки в завершении этапа.
Жесткие временные графики.
Сосредоточьтесь на доставке в срок, пропуская тестирование.

Кроме того, в подходе Test-Last часто пропускается модульное тестирование, которое должно выполняться разработчиками. Различные найденные причины основаны на мировоззрении разработчиков:

Они разработчики, а не тестировщики.
За тестирование отвечают тестировщики.
Они эффективны в кодировании, и их код не имеет дефектов.

Это приводит к -

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

Эти факторы потребовали изменения парадигмы, чтобы сосредоточиться на тестировании. Результатом стал подход Test-First.

Подход Test-First

Подход Test-First заменяет внутренний (напишите код, а затем тестируйте) на внешний (напишите тест, а затем код) способ разработки.

Этот подход включен в следующие методологии разработки программного обеспечения (которые также являются Agile):

еXTreme Pпрограммирование (XP).
Tстандартное восточное время Dрасколотый Dразвитие (TDD).

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

Важно отметить, что целью является разработка на основе тестирования.

Цикл "красный-зеленый-рефакторинг"

Разработка через тестирование используется для разработки кода с помощью модульных тестов.

Step 1 - Рассмотрим модуль кода, который нужно написать.

Step 2 - Напишите тест

Step 3 - Запустите тест.

Тест не проходит, так как код все еще не написан. Следовательно, шаг 2 обычно называется написанием теста на сбой.

Step 4 - Напишите минимально возможное количество кода, чтобы пройти тест.

Step 5- Запустите все тесты, чтобы убедиться, что все они проходят. Модульные тесты автоматизированы, чтобы облегчить этот шаг.

Step 6 - Рефакторинг.

Step 7 - Повторите шаги с 1 по 6 для следующего модуля кода.

Каждый цикл должен быть очень коротким, а обычный час должен состоять из множества циклов.

Это также широко известно как Red-Green-Refactor цикл, где -

Red - Написание неудачного теста.
Green - Написание кода для прохождения теста.
Refactor - Убрать дублирование и улучшить код до приемлемых стандартов.

Этапы процесса TDD

Шаги процесса TDD показаны ниже.

Преимущества TDD

Преимущества или преимущества разработки через тестирование:

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

Недостатки TDD

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

Когда тестировать?
Что тестировать?
Как узнать, соответствует ли спецификация?
Приносит ли код ценность для бизнеса?

Заблуждения о TDD

Следующие заблуждения существуют в отрасли и нуждаются в разъяснении.

Заблуждение	Разъяснение
TDD - это тестирование и автоматизация тестирования.	TDD - это методология разработки с использованием подхода Test-First.
TDD не предполагает никакого дизайна.	TDD включает критический анализ и проектирование на основе требований. Дизайн появляется в процессе разработки.
TDD есть только на уровне юнита.	TDD можно использовать на уровне интеграции и системы.
TDD не может использоваться в традиционных проектах тестирования.	TDD стал популярным среди экстремального программирования и используется в других методологиях Agile. Однако его можно использовать и в традиционных проектах тестирования.
TDD - это инструмент.	TDD - это методология разработки, и после каждого прохождения нового модульного теста она добавляется в набор тестов автоматизации, поскольку все тесты необходимо запускать всякий раз, когда добавляется новый код или изменяется существующий код, а также после каждого рефакторинга. Таким образом, средства автоматизации тестирования, поддерживающие TDD, облегчают этот процесс.
TDD означает передачу разработчикам приемочных тестов.	TDD не означает передачу разработчикам приемочных испытаний.

Принятие TDD

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

Ключевые практики в ATDD следующие:

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

Преимущества использования ATDD следующие:

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

TDD против BDD

По словам Дэна Норта, программисты обычно сталкиваются со следующими проблемами при выполнении разработки через тестирование:

Когда начать
Что тестировать, а что не тестировать
Сколько тестировать за один раз
Как назвать свои тесты
Как понять, почему тест не проходит

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

Главный difference between TDD and BDD это -

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

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

TDD заставляет задуматься о необходимых Behavior и, следовательно, термин "поведение" более полезен, чем термин ‘Test’. BDD - это разработка, управляемая тестированием, со словарем, который фокусируется на поведении, а не на тестах.

По словам Дэна Норта: «Я обнаружил, что переход от мышления с помощью тестов к мышлению с помощью поведения настолько глубок, что я начал называть TDD как BDD, или разработка, управляемая поведением». TDD фокусируется на том, как что-то будет работать, BDD фокусируется на том, зачем мы вообще это создаем.

BDD отвечает на следующие вопросы, с которыми часто сталкиваются разработчики:

Вопрос	Ответ
Когда начать?	снаружи
Что тестировать?	Истории пользователей
Что не тестировать?	что-нибудь еще

Эти ответы приводят к следующей структуре истории:

Story Framework

Как [Role]

я хочу [Feature]

так что [Benefit]

Это означает: «Когда Feature выполняется, в результате Benefit для человека, играющего Role.'

BDD также отвечает на следующие вопросы -

Вопрос	Ответ
Сколько тестировать за один раз?	очень мало сфокусированный
Как назвать их тесты?	шаблон предложения
Как понять, почему тест не проходит	документация

Эти ответы приводят к следующей структуре примера:

Example Framework

Given некоторый начальный контекст,

When событие происходит,

Then обеспечить некоторые результаты.

Это означает: «Начиная с начального контекста, когда происходит конкретное событие, мы знаем, какие результаты should be. '

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

История и сценарии

Давайте рассмотрим следующую иллюстрацию Дэна Норта о системе банкоматов.

Сказка

As a клиент,

I want снимать наличные в банкомате,

so that Мне не нужно стоять в очереди в банке.

Сценарии

У этой истории есть два возможных сценария.

Scenario 1 - Счет в кредит

Given счет в кредите

And карта действительна

And в диспенсере есть наличные

When клиент просит наличные

Then обеспечить дебетование счета

And обеспечить выдачу наличных

And убедитесь, что карта возвращена

Scenario 2 - Счет превышает лимит овердрафта

Given счет овердрафт

And карта действительна

When клиент просит наличные

Then убедитесь, что отображается сообщение об отказе

And убедитесь, что наличные не выдаются

And убедитесь, что карта возвращена

Событие одинаково в обоих сценариях, но контекст разный. Следовательно, результаты разные.

Цикл разработки

Цикл разработки BDD - это outside-in подход.

Step 1- Напишите пример бизнес-ценности высокого (внешнего) уровня (с использованием Cucumber или RSpec / Capybara), который станет красным. (RSpec создает структуру BDD на языке Ruby)

Step 2 - Напишите пример RSpec нижнего уровня (внутри) для первого шага реализации, который станет красным.

Step 3 - Реализуйте минимальный код для передачи этого примера нижнего уровня, чтобы он стал зеленым.

Step 4 - Напишите следующий пример RSpec более низкого уровня, подталкивающий к прохождению шага 1, который становится красным.

Step 5 - Повторяйте шаги Шаг 3 и Шаг 4, пока высокоуровневый пример на Шаге 1 не станет зеленым.

Note - Следует иметь в виду следующие моменты -

Red/green state - это статус разрешения.
Когда ваши низкоуровневые тесты имеют зеленый цвет, у вас есть разрешение на написание новых примеров или рефакторинг существующей реализации. Вы не должны в контексте рефакторинга добавлять новые функциональные возможности / гибкость.
Когда ваши низкоуровневые тесты красные, у вас есть разрешение на запись или изменение кода реализации только для того, чтобы существующие тесты стали зелеными. Вы должны сопротивляться желанию написать код для прохождения следующего теста, которого не существует, или реализовать функции, которые вы считаете хорошими (заказчик не спросил бы).

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

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

Спецификация на примере - Обзор

Задача Спецификации на примере - сосредоточиться на разработке и доставке приоритетных, проверяемых бизнес-требований. Хотя сама по себе концепция спецификации на примере относительно нова, это просто перефразирование существующих практик.

Он поддерживает очень конкретный краткий словарь, известный как вездесущий язык, который:

Включает исполняемые требования.
Используется всеми в команде.
Создан кросс-функциональной командой.
Улавливает понимание каждого.

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

Цель спецификации на примере

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

Использование SbE

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

Тестируется без перевода.
Записано в живой документации.

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

Их легче понять.
Их труднее неверно истолковать.

Преимущества SbE

Преимущества использования Спецификации на примере:

Повышенное качество
Сокращение отходов
Сниженный риск производственных дефектов
Сосредоточенные усилия
Изменения можно вносить более безопасно
Повышение вовлеченности бизнеса

Приложения SbE

Спецификация на примере найти приложения в -

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

SbE и приемочные испытания

Преимущества спецификации на примере с точки зрения приемочных испытаний:

Одна иллюстрация используется как для подробных требований, так и для тестирования.
Прогресс проекта в части приемочных испытаний -
- Каждый тест предназначен для проверки поведения.
- Тест либо проходит успешно, либо нет.
- Прохождение теста означает, что определенное поведение выполнено.
- Если в проекте, требующем выполнения 100 вариантов поведения, выполнено 60 вариантов поведения, то он завершен на 60%.
Тестировщики переключаются с исправления дефектов на предотвращение дефектов и вносят свой вклад в разработку решения.
Автоматизация позволяет мгновенно понять влияние изменения требований на решение.

Уточнение на примере - что это значит для разных ролей

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

Роль	Использование SbE
Бизнес-аналитик	Требования однозначны и без функциональных пробелов. Разработчики, собственно говоря, ознакомьтесь со спецификациями.
Разработчик	Разработчики лучше понимают, что разрабатывается. Прогресс разработки лучше отслеживается путем подсчета правильно разработанных спецификаций.
Тестер	Тестировщики лучше понимают, что тестируется. Тестировщики участвуют с самого начала и играют важную роль в проектировании. Тестировщики работают над предотвращением дефектов, а не с обнаружением дефектов.
Все	Экономия времени за счет выявления ошибок с самого начала. С самого начала производится качественный продукт.

SbE - Набор шаблонов процессов

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

Шаблоны процесса -

Совместная спецификация
Иллюстрирование спецификаций на примерах
Уточнение спецификации
Примеры автоматизации
Часто проверять
Живая документация

Совместная спецификация

Цели совместной спецификации:

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

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

During the meeting −

Бизнес-аналитик (BA) представляет требования и тесты для новой функции.
Три Amigos (BA, Developer и QA) обсуждают новую функцию и изучают спецификации.
QA и разработчик также определяют недостающие требования.
Три Амигоса
- Используйте общую модель, используя повсеместный язык.
- Используйте словарь предметной области (при необходимости ведется глоссарий).
- Ищите различия и конфликты.
Не переходите к деталям реализации на этом этапе.
Достигните консенсуса относительно того, достаточно ли указана функция.
Общее понимание требований и владение тестами способствуют разработке требований к качеству
Требования представлены в виде сценариев, которые содержат явные, недвусмысленные требования. Сценарий - это пример поведения системы с точки зрения пользователей.

Иллюстрация спецификации на примерах

Сценарии указываются с использованием структуры Given-When-Then для создания проверяемой спецификации -

Given <некоторое предварительное условие>

And <дополнительные условия> Optional

When <происходит действие / триггер>

Then <какое-то условие публикации>

And <дополнительные условия публикации> Optional

Эта спецификация является примером поведения системы. Он также представляет собой критерий приемлемости системы.

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

Уточнение спецификации

Чтобы уточнить спецификацию,

Будьте точны при написании примеров. Если пример оказывается сложным, разбейте его на более простые примеры.
Сосредоточьтесь на деловой перспективе и избегайте технических деталей.
Учитывайте как положительные, так и отрицательные условия.
Придерживайтесь лексики предметной области.
Обсудите примеры с заказчиком.
- Выберите разговоры, чтобы добиться этого.
- Учитывайте только те примеры, которые интересны заказчику. Это позволяет создавать только требуемый код и позволяет избежать охвата всех возможных комбинаций, которые могут не потребоваться.
Чтобы гарантировать, что сценарий проходит, все тестовые примеры для этого сценария должны пройти. Следовательно, улучшите спецификации, чтобы сделать их тестируемыми. Тестовые примеры могут включать в себя различные диапазоны и значения данных (граничные и угловые варианты), а также различные бизнес-правила, приводящие к изменениям данных.
Укажите дополнительные бизнес-правила, такие как сложные вычисления, обработка / преобразование данных и т. Д.
Включите нефункциональные сценарии (например, производительность, нагрузка, удобство использования и т. Д.) В качестве спецификации на примере

Примеры автоматизации

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

Выполните автоматизацию тестирования с использованием предметно-ориентированного языка (DSL) и покажите четкую связь между входами и выходами. Сосредоточьтесь на спецификации, а не на сценарии. Убедитесь, что тесты являются точными, легкими для понимания и проверяемыми.

Часто проверять

Включите пример проверки в конвейер разработки при каждом изменении (добавлении / модификации). Существует множество методов и инструментов, которые можно (и нужно) использовать, чтобы гарантировать качество продукта. Они вращаются вокруг трех ключевых принципов:Test Early, Test Well и Test Often.

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

Живая документация

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

Спецификация на примерах этапов процесса

На иллюстрации показаны этапы процесса в Спецификации на примере.

Анти-паттерны

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

Антипаттерны порождают различные проблемы.

Анти-шаблон	Проблемы
Нет сотрудничества	Многие предположения Строить неправильную вещь Тестирование неправильной вещи Не знает, когда код закончен
Не знает, когда код закончен	Трудно поддерживать тесты Трудно понять спецификацию Потеря интереса со стороны представителей бизнеса
Слишком подробные или слишком ориентированные на UI примеры	Трудно поддерживать тесты Трудно понять спецификации Потеря интереса со стороны представителей бизнеса
Требуется недооценка усилий	Команды думают, что потерпели неудачу, и рано разочаровываются

Решение проблем - качество

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

Соберитесь вместе, чтобы уточнить на примерах.
Очистите и улучшите примеры.
Напишите код, который удовлетворяет примерам
Автоматизируйте примеры и разверните.
Повторите этот подход для каждой пользовательской истории.

Решить проблемы из-за антипаттернов означает соблюдение -

Collaboration.
Сосредоточение внимания на чем.
Ориентация на бизнес.
Будь готов.

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

Сотрудничество

В сотрудничестве -

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

Сосредоточившись на чем

Вы должны сосредоточиться на вопросе - «что». Сосредоточившись на «что» -

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

Ориентация на бизнес

Чтобы сосредоточиться на бизнесе -

Соблюдайте спецификацию в соответствии с бизнес-намерениями.
Включите бизнес в создание и рассмотрение спецификаций.
Скройте все детали на слое автоматизации.

Будь готов

Будьте готовы к следующему -

Выгоды не очевидны сразу, даже если изменились методы работы в команде.
Внедрить SbE непросто.
Требует времени и вложений.
Автоматическое тестирование не предоставляется бесплатно.

инструменты

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

Следующие инструменты поддерживают спецификацию на примере -

Cucumber
SpecFlow
Fitnesse
Jbehave
Concordion
Behat
Jasmine
Relish
Speclog

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

Несколько инструментов BDD используются для разных платформ и языков программирования. Они -

Огурец (Рубиновый фреймворк)
SpecFlow (платформа .NET)
Поведение (фреймворк Python)
JBehave (среда Java)
JBehave Web (инфраструктура Java с интеграцией Selenium)
Салат-латук (фреймворк Python)
Concordion (среда Java)
Behat (фреймворк PHP)
Кэлен (фреймворк PHP)
DaSpec (фреймворк JavaScript)
Жасмин (фреймворк JavaScript)
Cucumber-js (фреймворк JavaScript)
Squish GUI Tester (Инструмент тестирования графического интерфейса BDD для JavaScript, Python, Perl, Ruby и Tcl)
Спок (Groovy framework)
Yadda (поддержка языка Gherkin для таких фреймворков, как Jasmine (фреймворк JavaScript))

Огурец

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

Огурец - основные характеристики

Ключевые особенности огурца следующие:

Огурец можно использовать для исполняемых спецификаций, автоматизации тестирования и живой документации.
Cucumber работает с Ruby, Java, NET, Flex или веб-приложениями, написанными на любом языке.
Cucumber поддерживает более сжатые тесты в таблицах - аналогично тому, что делает FIT.
Cucumber произвел революцию в жизненном цикле разработки программного обеспечения, объединив требования, автоматизированное тестирование и документацию в единое целое: спецификации исполняемых файлов в виде простого текста, которые подтверждают правильность программного обеспечения.

SpecFlow

SpecFlow - это инструмент BDD для платформы .NET. SpecFlow - проект с открытым исходным кодом. Исходный код размещен на GitHub.

SpecFlow использует синтаксис Gherkin для функций. Формат Gherkin был введен Cucumber и также используется другими инструментами. Язык Gherkin поддерживается как проект на GitHub -https://github.com/cucumber/gherkin

Вести себя

Behave используется для фреймворка Python.

Behave работает с тремя типами файлов, хранящимися в каталоге под названием «функции»:
- файлы функций с вашими сценариями поведения в нем.
- Каталог «steps» с реализациями шагов Python для сценариев.
- По желанию, некоторые элементы управления средой (код для запуска до и после шагов, сценариев, функций или всего матча).
Функции поведения написаны с использованием Gherkin (с некоторыми изменениями) и названы «name.feature».
Теги, прикрепленные к функции и сценарию, доступны в функциях среды через переданный им объект «функция» или «сценарий». У этих объектов есть атрибут, называемый «тегами», который представляет собой список прикрепленных имен тегов в том порядке, в котором они находятся в файле функций.
Модификации стандарта Gherkin Standard -
- Behave может анализировать стандартные файлы Gherkin и расширяет Gherkin, чтобы разрешить ключевые слова с шагом в нижнем регистре, потому что они иногда могут позволить более удобочитаемые спецификации функций

Салат

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

Concordion

Concordion - это инструмент с открытым исходным кодом для автоматизации спецификации на примере для Java Framework.

Хотя основные функции просты, API платформы Powerful extension framework позволяет добавлять функции, такие как использование электронных таблиц Excel в качестве спецификаций, добавление снимков экрана к выходным данным, отображение информации журнала и т. Д.

Concordion позволяет писать спецификации на обычном языке, используя абзацы, таблицы и правильную пунктуацию, а в структурированном языке с использованием Given / When / Then нет необходимости.

Concordion был перенесен на другие языки, включая -

C # (Concordion.NET)
Python (PyConcordion)
Рубин (Ruby-Concordion)

Cucumber - это инструмент, который поддерживает исполняемые спецификации, автоматизацию тестирования и живую документацию.

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

В key features исполняемых спецификаций следующие -

Исполняемые спецификации:
- На основе примеров, представляющих поведение системы.
- Написано при сотрудничестве всех, кто участвует в разработке, включая бизнес и заинтересованные стороны.
- По критерию приемки.
Приемочные испытания, основанные на исполняемых спецификациях, автоматизированы.
Общий, повсеместный язык используется для написания исполняемых спецификаций и автоматических тестов, чтобы:
- На протяжении всей разработки используется терминология, специфичная для предметной области.
- Все, включая клиентов и заинтересованных лиц, одинаково говорят о системе, ее требованиях и реализации.
- Те же термины используются для описания системы, представленной в требованиях, проектной документации, кодексе, тестах и т. Д.
- Любой желающий может прочитать и понять требование и способы создания дополнительных требований.
- Изменения могут быть легко внесены.
- Поддерживается живая документация.

Cucumber помогает в этом процессе, поскольку связывает исполняемые спецификации с фактическим кодом системы и автоматическими приемочными испытаниями.

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

Типичный приемочный тест огурца

Рассмотрим следующий пример.

Feature − Sign up

Регистрация должна быть быстрой и дружелюбной.
Сценарий - Успешная регистрация
- New пользователи должны получить электронное письмо с подтверждением и лично приветствовать их.
- Given Я решил зарегистрироваться.
- When Я регистрируюсь с действительными данными.
- Then Я должен получить электронное письмо с подтверждением.
- And Я должен увидеть персональное приветственное сообщение.

Из этого примера мы видим, что -

Приемочные испытания относятся к Features.
Особенности объясняются Scenarios.
Сценарии состоят из Steps.

Спецификация написана на естественном языке в виде простого текстового файла, но является исполняемой.

Работа огурца

Cucumber - это инструмент командной строки, который обрабатывает текстовые файлы, содержащие функции, для поиска сценариев, которые могут быть выполнены в вашей системе. Давайте разберемся, как работает огурец.

Он использует множество соглашений о том, как файлы именуются и где они расположены (соответствующие папки), чтобы упростить начало работы.
Cucumber позволяет хранить спецификации, автоматизированные тесты и документацию в одном месте.
Каждый сценарий представляет собой список шагов, которые описывают предварительные условия, действия и пост-условия сценария; если каждый шаг выполняется без какой-либо ошибки, сценарий помечается как пройденный.
В конце выполнения Cucumber сообщит, сколько сценариев прошло.
Если что-то не удается, он предоставляет информацию о том, что не удалось, чтобы разработчик мог продолжить.

В огурце, Features, Scenarios, а шаги написаны на языке, который называется Gherkin.

Gherkin - это текстовый английский (или один из более чем 60 других языков) со структурой. Gherkin легко выучить, а его структура позволяет писать примеры лаконично.

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

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

Отображение шагов и определений шагов

Ключ к Cucumber - это соответствие между шагами и определениями шагов.

Реализации огурца

Ниже приведены реализации Cucumber.

	Руби / JRuby
	JRuby (с использованием Cucumber-JVM)
	Ява
	Groovy
	.NET (с использованием SpecFlow)
	JavaScript
	JavaScript (с использованием Cucumber-JVM и Rhino)
	Clojure
	Госу
	Lua
	PHP (с использованием Behat)
	Jython
	C ++
	Tcl

Интеграция фреймворка

Ниже приведены реализации Framework.

	Рубин на рельсах
	Селен
	ПикоКонтейнер
	Spring Framework
	Ватир

Корнишон - это язык, на котором пишут Features, Scenarios, and Steps. Цель Gherkin - помочь нам написать конкретные требования.

Чтобы понять, что мы подразумеваем под конкретными требованиями, рассмотрим следующий пример -

Клиенты не должны вводить недействительные данные кредитной карты.

Против

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

Последний не имеет двусмысленности, позволяет избежать ошибок и гораздо более поддается проверке.

Gherkin создан для создания более конкретных требований. В Gherkin приведенный выше пример выглядит так:

Feature

Отзыв при вводе недействительных данных кредитной карты Feature Definition

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

Background True for all Scenarios Below

Given Я выбрал товар для покупки,

And Я собираюсь ввести номер своей кредитной карты

Scenario - слишком короткий номер кредитной картыScenario Definition

When Я ввожу номер карты, длина которого меньше 16 цифр

And все остальные детали верны

And Я отправляю формуSteps

Then форма должна быть повторно отображена

And Я должен увидеть сообщение с указанием правильного количества цифр

Формат и синтаксис Gherkin

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

Feature
Scenario
Дано, когда, тогда и, но (шаги)
Background
Схема сценария
Examples
"" "(Строки документа)
| (Таблицы данных)
@ (Теги)
# (Комментарии)
*

Характерная черта

В Featureключевое слово используется для описания функции программного обеспечения и для группировки связанных сценариев. Функция состоит из трех основных элементов:

Ключевое слово - Feature.
Имя функции, указанное в той же строке, что и ключевое слово Feature.
Необязательное (но настоятельно рекомендуемое) описание, которое может охватывать несколько строк, т.е. весь текст между строкой, содержащей ключевое слово Feature, и строкой, которая начинается с сценария, фона или схемы сценария.

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

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

feedback_when_entering_invalid_credit_card_details.feature

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

Для <достижения какой-то цели> как <тип пользователя> мне нужна <a feature>

Описания

Некоторые части документов Gherkin не обязательно должны начинаться с ключевого слова.

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

Сценарий

Чтобы выразить поведение вашей системы, вы присоединяете один или несколько сценариев к каждой функции. Обычно для каждой функции можно увидеть от 5 до 20 сценариев, чтобы полностью указать все действия, связанные с этой функцией.

Сценарии следуют следующему шаблону -

Опишите исходный контекст
Опишите событие
Опишите ожидаемый результат

Мы начинаем с контекста, описываем действие и проверяем результат. Это делается по шагам. Gherkin предлагает три ключевых слова для описания каждого из контекстов, действий и результатов в виде шагов.

Given - Установить контекст
When - Выполнить действие
Then - Проверить результат

Эти ключевые слова обеспечивают читаемость сценария.

Example

Scenario - Снять деньги со счета.

Given У меня на счету 100 долларов.
When Прошу 20 долларов.
Then Следует выделить 20 долларов.

Если есть несколько Given или же When шаги друг под другом, вы можете использовать And или же But. Они позволяют подробно указывать сценарии.

Example

Scenario - Попытка вывода средств с использованием украденной карты.

Given У меня на счету 100 долларов.
But моя карта недействительна.
When Прошу 50 долларов.
Then моя карта не подлежит возврату.
And Мне нужно сказать, чтобы я обратился в банк.

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

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

Такие сценарии обеспечивают следующие преимущества -

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

Схема сценария

Если вам нужно написать сценарии с несколькими входами или выходами, вы можете создать несколько сценариев, которые отличаются только своими значениями. Решение - использовать схему сценария. Чтобы написать план сценария,

Переменные в шагах схемы сценария помечены <и>.
Различные значения переменных приведены в качестве примеров в таблице.

Example

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

Feature - Добавить.

Scenario Outline: Add two numbers.
Given the input "<input>"
When the calculator is run
Then the output should be <output>"
Examples
| input    | output |
| 2+2      | 4      | 
| 98+1     | 99     |
| 255+390  | 645    |

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

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

Формат Gherkin был введен Cucumber и также используется другими инструментами. Язык Gherkin поддерживается как проект на GitHub -https://github.com/cucumber/gherkin

Элементы функций и SpecFlow

Ключевые особенности элементов Feature:

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

Несколько шагов сценария

Сценарии могут иметь несколько этапов сценария. Есть три типа шагов, которые определяют предварительные условия, действия или шаги проверки, которые составляют приемочное испытание.

Различные типы шагов начинаются с Given, When или же Then ключевые слова соответственно, и последующие шаги того же типа могут быть связаны с помощью And и But ключевые слова.
Синтаксис Gherkin допускает любую комбинацию этих трех типов шагов, но сценарий обычно имеет отдельные блоки Given, When и Then заявления.
Шаги сценария определяются с помощью текста и могут иметь дополнительную таблицу с именем DataTable или многострочный текст с именем DocString arguments.
Шаги сценария - это основной способ выполнения любого настраиваемого кода для автоматизации приложения.
SpecFlow генерирует вызов внутри метода модульного тестирования для каждого шага сценария. Вызов выполняется средой выполнения SpecFlow, которая выполнит определение шага, соответствующее шагу сценария.
Сопоставление выполняется во время выполнения, поэтому сгенерированные тесты могут быть скомпилированы и выполнены, даже если привязка еще не реализована.
В шаги сценария можно включать таблицы и многострочные аргументы. Они используются в определениях шагов и передаются в виде дополнительных табличных или строковых аргументов.

Теги - это маркеры, которые можно назначать функциям и сценариям. Назначение тега функции эквивалентно назначению тега всем сценариям в файле функции. Имя тега с начальным символом @ обозначает тег.

Если это поддерживается платформой модульного тестирования, SpecFlow генерирует категории из тегов.
Созданное имя категории такое же, как имя тега, но без символа @ в начале.
Вы можете фильтровать и группировать тесты, которые нужно выполнить, используя эти категории модульных тестов. Например, вы можете пометить важные тесты с помощью @important, а затем выполнять эти тесты чаще.

Элементы фона

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

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

Контуры сценария

Схемы сценария могут использоваться для определения приемочных испытаний на основе данных. Схема сценария всегда состоит из спецификации шаблона сценария (сценарий с заполнителями данных с использованием синтаксиса <placeholder>) и набора примеров, которые предоставляют значения для заполнителей.

Если платформа модульного тестирования поддерживает это, SpecFlow генерирует тесты на основе строк из схем сценария.
В противном случае он генерирует параметризованный логический метод модульного тестирования для схемы сценария и индивидуальный метод модульного тестирования для каждого набора примеров.
Для лучшей прослеживаемости сгенерированные имена методов модульного тестирования являются производными от заголовка схемы сценария и первого значения примеров (первый столбец таблицы примеров).
Поэтому рекомендуется выбирать уникальный и описательный параметр в качестве первого столбца в наборе примеров.
Поскольку синтаксис Gherkin требует, чтобы все столбцы примеров имели соответствующие заполнители в схеме сценария, вы даже можете ввести произвольный столбец в наборы примеров, используемые для именования тестов с большей удобочитаемостью.
SpecFlow выполняет замену заполнителя как отдельный этап перед сопоставлением привязок шагов.
Таким образом, реализация и параметры в привязках шагов не зависят от того, выполняются ли они посредством прямого сценария или схемы сценария.
Это позволяет позже указать дополнительные примеры в приемочных тестах без изменения привязки шагов.

Вы можете добавлять строки комментариев к файлам функций в любом месте, начав строку с символа #. Однако будьте осторожны, поскольку комментарии в вашей спецификации могут быть признаком того, что критерии приемки были указаны неправильно. SpecFlow игнорирует строки комментариев.