Поведенческая разработка — Введение

Behavior Driven Development (BDD) — это процесс разработки программного обеспечения, который первоначально возник из Test Driven Development (TDD).

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

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

• Преобразован в исполняемые спецификации.

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

Преобразован в исполняемые спецификации.

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

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

Behavior Driven Development фокусируется на —

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

• Что должна делать система, а не то, как она должна быть реализована.

• Обеспечение лучшей читаемости и видимости.

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

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

Что должна делать система, а не то, как она должна быть реализована.

Обеспечение лучшей читаемости и видимости.

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

Происхождение БДД

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

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

Необходимость часа — это подход к развитию, который —

• Основано на требованиях.

• Ориентирован на требования на протяжении всей разработки.

• Гарантирует, что требования выполнены.

Основано на требованиях.

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

Гарантирует, что требования выполнены.

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

• Получает примеры различных ожидаемых поведений системы.

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

• Получает примеры, утверждаемые время от времени с помощью разговоров.

• Ориентирован на требования заказчика (примеры) на протяжении всей разработки.

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

Получает примеры различных ожидаемых поведений системы.

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

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

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

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

BDD Практики

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

• Спецификация по примеру (SbE)

• Разработка через тестирование (TDD)

Спецификация по примеру (SbE)

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

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

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

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

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

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

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

Agile BDD

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

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

• Разработчики и владелец продукта совместно пишут ожидающие спецификации в текстовом редакторе.

• Владелец продукта указывает поведение, которое они ожидают от системы.

• Разработчики

  • Заполните спецификации этими подробностями поведения.

  • Задайте вопросы, основанные на их понимании системы.

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

Разработчики и владелец продукта совместно пишут ожидающие спецификации в текстовом редакторе.

Владелец продукта указывает поведение, которое они ожидают от системы.

Разработчики

Заполните спецификации этими подробностями поведения.

Задайте вопросы, основанные на их понимании системы.

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

Agile Manifesto и BDD

Agile Manifesto гласит следующее:

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

• Индивидуумы и взаимодействия — над процессами и инструментами

• Рабочее программное обеспечение — более полная документация

• Взаимодействие с клиентами — более договорные переговоры

• Реагирование на изменения — по плану

Индивидуумы и взаимодействия — над процессами и инструментами

Рабочее программное обеспечение — более полная документация

Взаимодействие с клиентами — более договорные переговоры

Реагирование на изменения — по плану

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

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

Agile Manifesto	Выравнивание BDD
Люди и взаимодействия по процессам и инструментам.	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 заменяет наизнанку (запись кода, а затем тестирование) на разработку извне (запись, а затем код).

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

• e X treme P программирование ( XP ).

• Тестирование развития (TDD).

e X treme P программирование ( XP ).

Тестирование развития (TDD).

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

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

Красный-Зеленый-Реактор Цикл

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

Шаг 1 — Рассмотрим модуль кода, который должен быть написан.

Шаг 2 — Написать тест

Шаг 3 — Запустите тест.

Тест не пройден, так как код все еще не написан. Следовательно, Шаг 2 обычно называется «написать тест на неудачу».

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

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

Шаг 6 — Рефакторинг.

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

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

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

• Красный — написание теста, который не проходит.

• Зеленый — Написание кода для прохождения теста.

• Refactor — Устранить дублирование и улучшить код до приемлемых стандартов.

Красный — написание теста, который не проходит.

Зеленый — Написание кода для прохождения теста.

Refactor — Устранить дублирование и улучшить код до приемлемых стандартов.

Шаги процесса TDD

Этапы процесса TDD проиллюстрированы ниже.

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

Преимущества или преимущества Test Driven Development — это

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

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

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

• Модульные тесты действуют как живая документация, которая всегда соответствует данным.

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

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

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

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

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

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

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

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

Модульные тесты действуют как живая документация, которая всегда соответствует данным.

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

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

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

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

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

Недостатки TDD

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

• Когда тестировать?

• Что проверить?

• Как узнать, соответствует ли спецификация?

• Предоставляет ли код ценность для бизнеса?

Когда тестировать?

Что проверить?

Как узнать, соответствует ли спецификация?

Предоставляет ли код ценность для бизнеса?

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

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

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

TDD — это методология разработки, и после каждого нового модульного теста он добавляется в Automation Test Suite, поскольку все тесты необходимо запускать при добавлении нового кода или изменении существующего кода, а также после каждого рефакторинга.

Таким образом, средства автоматизации тестирования, поддерживающие TDD, облегчают этот процесс.

Принятие TDD

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

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

• Обсудите реальные сценарии, чтобы построить общее понимание предметной области.

• Используйте эти сценарии, чтобы прийти к критериям приемлемости.

• Автоматизировать приемочные испытания.

• Сосредоточьте разработку на этих тестах.

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

Обсудите реальные сценарии, чтобы построить общее понимание предметной области.

Используйте эти сценарии, чтобы прийти к критериям приемлемости.

Автоматизировать приемочные испытания.

Сосредоточьте разработку на этих тестах.

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

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

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

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

• Приемочные тесты направляют разработку.

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

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

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

TDD против BDD

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

• Когда начать

• Что проверять, а что не проверять

• Сколько тестировать за один раз

• Как назвать свои тесты

• Как понять, почему тест не пройден

Когда начать

Что проверять, а что не проверять

Сколько тестировать за один раз

Как назвать свои тесты

Как понять, почему тест не пройден

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

Основное различие между TDD и BDD заключается в том, что —

• TDD описывает, как работает программное обеспечение.

• С другой стороны, BDD —

  • Описывает, как конечный пользователь использует программное обеспечение.

  • Способствует сотрудничеству и общению.

  • Подчеркивает на примерах поведения Системы.

  • Цели в исполняемых спецификациях, полученных из примеров

TDD описывает, как работает программное обеспечение.

С другой стороны, BDD —

Описывает, как конечный пользователь использует программное обеспечение.

Способствует сотрудничеству и общению.

Подчеркивает на примерах поведения Системы.

Цели в исполняемых спецификациях, полученных из примеров

BDD — TDD в виде BDD

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

TDD заставляет задуматься о требуемом поведении, и поэтому термин «поведение» более полезен, чем термин «тест» . BDD — это разработка через тестирование со словарем, который фокусируется на поведении, а не на тестах.

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

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

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

Эти ответы приводят к структуре истории следующим образом —

Рамочная история

Как [роль]

Я хочу [Особенность]

так что [выгода]

Это означает: «Когда функция выполняется, получаемая выгода для лица, играющего роль. ‘

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

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

Эти ответы приводят в пример структуры следующим образом —

Пример платформы

Учитывая некоторый начальный контекст,

Когда происходит событие,

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

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

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

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

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

История

Как клиент,

Я хочу снять наличные в банкомате,

так что мне не нужно ждать очереди в банке.

Сценарии

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

Сценарий 1 — счет в кредит

Учитывая, что счет в кредит

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

И диспенсер содержит деньги

Когда клиент просит наличные

Затем убедитесь, что учетная запись списана

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

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

Сценарий 2 — Счет превышен лимит овердрафта

Учитывая, что счет снят

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

Когда клиент просит наличные

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

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

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

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

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

Цикл разработки для BDD является внешним подходом.

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

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

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

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

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

Примечание . Необходимо учитывать следующее:

• Красный / зеленый статус — это статус разрешения.

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

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

Красный / зеленый статус — это статус разрешения.

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

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

BDD — спецификации на примере

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

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

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

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

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

• Включает исполняемые требования.

• Используется всеми в команде.

• Создан многофункциональной командой.

• Захватывает понимание каждого.

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

Используется всеми в команде.

Создан многофункциональной командой.

Захватывает понимание каждого.

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

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

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

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

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

• Тестируется без перевода.

• Захвачено в живой документации.

Тестируется без перевода.

Захвачено в живой документации.

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

• Их легче понять.

• Их сложнее неправильно понять.

Их легче понять.

Их сложнее неправильно понять.

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

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

• Повышенное качество

• Уменьшенные отходы

• Снижение риска производственных дефектов

• Сосредоточенное усилие

• Изменения могут быть сделаны более безопасно

• Улучшенное участие бизнеса

Повышенное качество

Уменьшенные отходы

Снижение риска производственных дефектов

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

Изменения могут быть сделаны более безопасно

Улучшенное участие бизнеса

Применение SbE

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

• Сложный бизнес или сложная организация.

• Не работает для чисто технических проблем.

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

• Может применяться и к устаревшим системам.

Сложный бизнес или сложная организация.

Не работает для чисто технических проблем.

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

Может применяться и к устаревшим системам.

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

Преимущества Specification by Example с точки зрения приемочного тестирования:

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

• Прогресс проекта с точки зрения приемочных испытаний —

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

  • Тест либо проходит на поведение, либо нет.

  • Проходной тест показывает, что конкретное поведение завершено.

  • Если для проекта, требующего 100 вариантов поведения, выполнено 60 вариантов поведения, то он завершен на 60%.

• Тестеры переходят от устранения дефектов к предотвращению дефектов, и они вносят вклад в разработку решения.

• Автоматизация позволяет мгновенно понять влияние изменения требований на решение.

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

Прогресс проекта с точки зрения приемочных испытаний —

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

Тест либо проходит на поведение, либо нет.

Проходной тест показывает, что конкретное поведение завершено.

Если для проекта, требующего 100 вариантов поведения, выполнено 60 вариантов поведения, то он завершен на 60%.

Тестеры переходят от устранения дефектов к предотвращению дефектов, и они вносят вклад в разработку решения.

Автоматизация позволяет мгновенно понять влияние изменения требований на решение.

Спецификация на примере — что это значит для разных ролей

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

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

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

Разработчики, на самом деле читают спецификации.

Разработчики лучше понимают, что разрабатывается.

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

Тестеры лучше понимают, что тестируется.

Тестеры участвуют с самого начала и играют определенную роль в дизайне.

Тестеры работают в направлении предотвращения дефектов, а не обнаружения дефектов.

Время экономится путем выявления ошибок с самого начала.

Качественный продукт производится с самого начала.

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

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

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

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

• Иллюстрируя спецификации, используя примеры

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

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

• Проверять часто

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

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

Иллюстрируя спецификации, используя примеры

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

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

Проверять часто

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

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

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

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

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

• Обеспечить совместное общение и владение функциями.

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

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

Обеспечить совместное общение и владение функциями.

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

Во время встречи —

• Business Analyst (BA) представляет требования и тесты для новой функции.

• Три Amigos (BA, Developer и QA) обсуждают новую функцию и рассматривают спецификации.

• QA и разработчик также определяют отсутствующие требования.

• Три Амиго

  • Используйте общую модель, используя вездесущий язык.

  • Использовать словарь домена (при необходимости поддерживается глоссарий).

  • Ищите различия и конфликты.

• Не переходите к деталям реализации на этом этапе.

• Достигните консенсуса относительно того, была ли функция указана достаточно.

• Общее понимание требований и владение тестами облегчает качество спецификаций

• Требования представлены в виде сценариев, которые обеспечивают явные, однозначные требования. Сценарий является примером поведения системы с точки зрения пользователей.

Business Analyst (BA) представляет требования и тесты для новой функции.

Три Amigos (BA, Developer и QA) обсуждают новую функцию и рассматривают спецификации.

QA и разработчик также определяют отсутствующие требования.

Три Амиго

Используйте общую модель, используя вездесущий язык.

Использовать словарь домена (при необходимости поддерживается глоссарий).

Ищите различия и конфликты.

Не переходите к деталям реализации на этом этапе.

Достигните консенсуса относительно того, была ли функция указана достаточно.

Общее понимание требований и владение тестами облегчает качество спецификаций

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

Иллюстрирование спецификации с использованием примеров

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

Учитывая <некоторое предварительное условие>

И <дополнительные предварительные условия> Необязательно

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

Тогда <какое-то почтовое условие>

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

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

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

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

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

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

• Сосредоточьтесь на деловой перспективе и избегайте технических деталей.

• Учитывайте как положительные, так и отрицательные условия.

• Придерживайтесь предметной лексики.

• Обсудите примеры с заказчиком.

  • Выберите разговоры для достижения этой цели.

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

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

• Укажите дополнительные бизнес-правила, такие как сложные вычисления, обработка / преобразование данных и т. Д.

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

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

Сосредоточьтесь на деловой перспективе и избегайте технических деталей.

Учитывайте как положительные, так и отрицательные условия.

Придерживайтесь предметной лексики.

Обсудите примеры с заказчиком.

Выберите разговоры для достижения этой цели.

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

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

Укажите дополнительные бизнес-правила, такие как сложные вычисления, обработка / преобразование данных и т. Д.

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

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

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

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

Проверка часто

Включайте пример проверки в свой конвейер разработки при каждом изменении (добавление / изменение). Существует множество методов и инструментов, которые можно (и нужно) применять для обеспечения качества продукта. Они основаны на трех ключевых принципах: « Тестируй рано», «Тестируй хорошо» и « Тестируй часто» .

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

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

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

Спецификация на примере шагов процесса

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

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

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

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

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

Много предположений

Строить неправильную вещь

Тестирование неправильной вещи

Не знаю, когда код закончен

Трудно поддерживать тесты

Трудно понять спецификацию

Потеря интереса со стороны представителей бизнеса

Трудно поддерживать тесты

Трудно понять спецификации

Потеря интереса со стороны представителей бизнеса

Команды считают, что потерпели неудачу и разочаровываются рано

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

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

• Собирайтесь, чтобы уточнить, используя примеры.

• Очистить и улучшить примеры.

• Напишите код, который удовлетворяет примерам

• Автоматизируйте примеры и разверните.

• Повторите подход для каждой пользовательской истории.

Собирайтесь, чтобы уточнить, используя примеры.

Очистить и улучшить примеры.

Напишите код, который удовлетворяет примерам

Автоматизируйте примеры и разверните.

Повторите подход для каждой пользовательской истории.

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

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

• Сосредоточиться на чем.

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

• Будь готов.

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

Сосредоточиться на чем.

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

Будь готов.

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

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

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

• Деловые люди, разработчики и тестировщики вносят свой вклад со своей точки зрения.

• Автоматизированные примеры доказывают, что команда построила правильную вещь.

• Процесс ценнее самих тестов.

Деловые люди, разработчики и тестировщики вносят свой вклад со своей точки зрения.

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

Процесс ценнее самих тестов.

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

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

• Не пытайтесь охватить все возможные случаи.

• Не забудьте использовать разные виды тестов.

• Приведите примеры как можно проще.

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

• Инструменты не должны играть важную роль в мастерских.

Не пытайтесь охватить все возможные случаи.

Не забудьте использовать разные виды тестов.

Приведите примеры как можно проще.

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

Инструменты не должны играть важную роль в мастерских.

Сосредоточиться на бизнесе

Сосредоточиться на бизнесе —

• Держите спецификацию в деловых целях.

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

• Скрыть все детали в слое автоматизации.

Держите спецификацию в деловых целях.

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

Скрыть все детали в слое автоматизации.

Будь готов

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

• Преимущества не сразу очевидны, даже если практика команды изменилась.

• Представить SbE сложно.

• Требует времени и вложений.

• Автоматическое тестирование не приходит бесплатно.

Преимущества не сразу очевидны, даже если практика команды изменилась.

Представить SbE сложно.

Требует времени и вложений.

Автоматическое тестирование не приходит бесплатно.

инструменты

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

Следующие инструменты поддерживают Specification by Example —

• Огурец

• SpecFlow

• Fitnesse

• JBehave

• Concordion

• Behat

• жасмин

• смаковать

• Speclog

Огурец

SpecFlow

Fitnesse

JBehave

Concordion

Behat

жасмин

смаковать

Speclog

Behavior Driven Development — Инструменты

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

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

• Огурец (Рубиновый каркас)

• SpecFlow (.NET Framework)

• Поведение (фреймворк Python)

• JBehave (фреймворк Java)

• JBehave Web (фреймворк Java с интеграцией Selenium)

• Салат (рамки Python)

• Concordion (фреймворк Java)

• Behat (фреймворк PHP)

• Kahlan (фреймворк PHP)

• DaSpec (фреймворк JavaScript)

• Жасмин (фреймворк JavaScript)

• Cucumber-js (фреймворк JavaScript)

• Squish GUI Tester (инструмент тестирования BDD GUI для JavaScript, Python, Perl, Ruby и Tcl)

• Спок (Groovy рамки)

• Yadda (поддержка языка Gherkin для таких платформ, как Jasmine (фреймворк JavaScript))

Огурец (Рубиновый каркас)

SpecFlow (.NET Framework)

Поведение (фреймворк Python)

JBehave (фреймворк Java)

JBehave Web (фреймворк Java с интеграцией Selenium)

Салат (рамки Python)

Concordion (фреймворк Java)

Behat (фреймворк PHP)

Kahlan (фреймворк PHP)

DaSpec (фреймворк JavaScript)

Жасмин (фреймворк JavaScript)

Cucumber-js (фреймворк JavaScript)

Squish GUI Tester (инструмент тестирования BDD GUI для JavaScript, Python, Perl, Ruby и Tcl)

Спок (Groovy рамки)

Yadda (поддержка языка Gherkin для таких платформ, как Jasmine (фреймворк JavaScript))

Огурец

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

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

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

• Огурец можно использовать для Исполняемых спецификаций, Автоматизации испытаний и Живая документация.

• Cucumber работает с Ruby, Java, NET, Flex или веб-приложениями, написанными на любом языке.

• Cucumber поддерживает более сжатые тесты в таблицах — аналогично тому, что делает FIT.

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

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

Cucumber работает с Ruby, Java, NET, Flex или веб-приложениями, написанными на любом языке.

Cucumber поддерживает более сжатые тесты в таблицах — аналогично тому, что делает FIT.

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

SpecFlow

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

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

Вести себя

Поведение используется для платформы Python.

• Behave работает с тремя типами файлов, которые хранятся в каталоге, называемом «функции» —

  • файлы функций с вашими сценариями поведения в нем.

  • Каталог «steps» с реализациями шагов Python для сценариев.

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

• Функции поведения написаны с использованием Gherkin (с некоторыми изменениями) и называются «name.feature».

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

• Изменения к стандарту корнишон —

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

Behave работает с тремя типами файлов, которые хранятся в каталоге, называемом «функции» —

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

Каталог «steps» с реализациями шагов Python для сценариев.

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

Функции поведения написаны с использованием Gherkin (с некоторыми изменениями) и называются «name.feature».

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

Изменения к стандарту корнишон —

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

Салат

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

Concordion

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

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

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

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

• C # (Concordion.NET)

• Python (PyConcordion)

• Рубин (Руби-Конкордеон)

C # (Concordion.NET)

Python (PyConcordion)

Рубин (Руби-Конкордеон)

Развитие, управляемое поведением — огурец

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

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

Ключевые особенности исполняемых спецификаций следующие:

• Исполняемые спецификации —

  • Получено из примеров, которые представляют поведение системы.

  • Написано с участием всех вовлеченных в разработку, в том числе бизнеса и заинтересованных сторон.

  • На основании критерия приемлемости.

• Приемочные испытания, основанные на исполняемых спецификациях, автоматизированы.

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

  • Специфичная для домена терминология используется на протяжении всей разработки.

  • Все, включая клиентов и заинтересованные стороны, одинаково говорят о системе, ее требованиях и ее внедрении.

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

  • Любой может прочитать и понять требование и как создать больше требований.

  • Изменения могут быть легко приспособлены.

  • Живая документация поддерживается.

Исполняемые спецификации —

Получено из примеров, которые представляют поведение системы.

Написано с участием всех вовлеченных в разработку, в том числе бизнеса и заинтересованных сторон.

На основании критерия приемлемости.

Приемочные испытания, основанные на исполняемых спецификациях, автоматизированы.

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

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

Все, включая клиентов и заинтересованные стороны, одинаково говорят о системе, ее требованиях и ее внедрении.

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

Любой может прочитать и понять требование и как создать больше требований.

Изменения могут быть легко приспособлены.

Живая документация поддерживается.

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

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

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

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

Особенность — Зарегистрироваться

• Регистрация должна быть быстрой и дружелюбной.

• Сценарий — Успешная регистрация

  • Новые пользователи должны получить подтверждение по электронной почте и быть встреченными лично.

  • Учитывая, что я решил зарегистрироваться.

  • Когда я зарегистрируюсь с действительными данными.

  • Затем я должен получить подтверждение по электронной почте.

  • И я должен увидеть персональное приветственное сообщение.

Регистрация должна быть быстрой и дружелюбной.

Сценарий — Успешная регистрация

Новые пользователи должны получить подтверждение по электронной почте и быть встреченными лично.

Учитывая, что я решил зарегистрироваться.

Когда я зарегистрируюсь с действительными данными.

Затем я должен получить подтверждение по электронной почте.

И я должен увидеть персональное приветственное сообщение.

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

• Приемочные испытания относятся к функциям .

• Особенности объясняются сценариями .

• Сценарии состоят из шагов .

Приемочные испытания относятся к функциям .

Особенности объясняются сценариями .

Сценарии состоят из шагов .

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

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

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

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

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

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

• В конце цикла Cucumber сообщит, сколько сценариев прошло.

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

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

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

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

В конце цикла Cucumber сообщит, сколько сценариев прошло.

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

В «Огурце» функции , сценарии и шаги написаны на языке под названием « корнишон» .

Огурец — это простой текстовый английский (или один из 60+ других языков) со структурой. Огурец прост в освоении, а его структура позволяет писать примеры в сжатой форме.

• Cucumber выполняет ваши файлы, которые содержат исполняемые спецификации, написанные в Gherkin.

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

• Когда Cucumber выполняет шаг в сценарии, он ищет соответствующее определение шага для выполнения.

• Определение шага — это небольшой фрагмент кода с прикрепленным к нему шаблоном.

• Шаблон используется для связывания определения шага со всеми соответствующими шагами, а код — это то, что Cucumber выполнит, когда увидит шаг корнишона.

• Каждый шаг сопровождается определением шага.

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

Cucumber выполняет ваши файлы, которые содержат исполняемые спецификации, написанные в Gherkin.

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

Когда Cucumber выполняет шаг в сценарии, он ищет соответствующее определение шага для выполнения.

Определение шага — это небольшой фрагмент кода с прикрепленным к нему шаблоном.

Шаблон используется для связывания определения шага со всеми соответствующими шагами, а код — это то, что Cucumber выполнит, когда увидит шаг корнишона.

Каждый шаг сопровождается определением шага.

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

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

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

Ключ к огурцу — это отображение между шагами и определениями шагов.

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

Ниже приведены реализации огурца.

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

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

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

	Рубин на рельсах
	Селен
	PicoContainer
	Spring Framework
	Watir

Поведенческая разработка — корнишон

Огурец — это язык, который используется для написания функций, сценариев и шагов . Цель Gherkin — помочь нам написать конкретные требования.

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

Клиенты должны быть защищены от ввода неверных данных кредитной карты.

Против

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

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

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

Особенность

Обратная связь при вводе неверных данных кредитной карты

В тестировании пользователей мы видели много людей, которые делают ошибки

Справедливо для всех сценариев ниже

Учитывая, что я выбрал предмет для покупки,

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

Сценарий — номер кредитной карты слишком короткий Определение сценария

Когда я ввожу номер карты длиной менее 16 цифр

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

И я отправляю форму Шаги

Тогда форма должна быть переиздана

И я должен увидеть сообщение, сообщающее мне правильное количество цифр

Огурец Формат и синтаксис

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

• Особенность

• сценарий

• Дано, Когда, Тогда, И, Но (Шаги)

• Фон

• План сценария

• Примеры

• «» «(Док Док)

• | (Таблицы данных)

• @ (Теги)

• # (Комментарии)

• *

Особенность

сценарий

Дано, Когда, Тогда, И, Но (Шаги)

Фон

План сценария

Примеры

«» «(Док Док)

| (Таблицы данных)

@ (Теги)

# (Комментарии)

*

Особенность

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

• Ключевое слово — Feature.

• Имя функции, указанное в той же строке, что и ключевое слово Feature.

• Необязательное (но настоятельно рекомендуется) описание, которое может занимать несколько строк, т. Е. Весь текст между строкой, содержащей ключевое слово Feature, и строкой, начинающейся с Scenario, Background или Scenario Outline.

Ключевое слово — Feature.

Имя функции, указанное в той же строке, что и ключевое слово Feature.

Необязательное (но настоятельно рекомендуется) описание, которое может занимать несколько строк, т. Е. Весь текст между строкой, содержащей ключевое слово Feature, и строкой, начинающейся с Scenario, Background или Scenario Outline.

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

Файл .feature обычно называют именем элемента, переводя его в нижний регистр и заменяя пробелы подчеркиванием. Например,

feedback_when_entering_invalid_credit_card_details.feature

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

Чтобы <достичь какой-то цели> как <тип пользователя>, я хочу <a функцию>

Описания

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

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

сценарий

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

Сценарии следуют следующей схеме —

• Опишите начальный контекст

• Опишите событие

• Опишите ожидаемый результат

Опишите начальный контекст

Опишите событие

Опишите ожидаемый результат

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

• Дано — установить контекст

• Когда — выполнить действие

• Потом — проверь результат

Дано — установить контекст

Когда — выполнить действие

Потом — проверь результат

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

пример

Сценарий — снятие денег со счета.

• Учитывая, что у меня есть 100 долларов на моем счете.

• Когда я запрашиваю 20 долларов.

• Тогда 20 долларов должны быть распределены.

Учитывая, что у меня есть 100 долларов на моем счете.

Когда я запрашиваю 20 долларов.

Тогда 20 долларов должны быть распределены.

Если несколько шагов « дано» или « когда» расположены друг под другом, вы можете использовать « И» или « Но» . Они позволяют детально указывать сценарии.

пример

Сценарий — попытка снятия с использованием украденной карты.

• Учитывая, что у меня есть 100 долларов на моем счете.

• Но моя карта недействительна.

• Когда я запрашиваю 50 долларов.

• Тогда моя карта не должна быть возвращена.

• И мне нужно сказать, чтобы связаться с банком.

Учитывая, что у меня есть 100 долларов на моем счете.

Но моя карта недействительна.

Когда я запрашиваю 50 долларов.

Тогда моя карта не должна быть возвращена.

И мне нужно сказать, чтобы связаться с банком.

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

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

• Каждый сценарий создает свой конкретный контекст, выполняет одну вещь и проверяет результат.

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

Каждый сценарий создает свой конкретный контекст, выполняет одну вещь и проверяет результат.

Такие сценарии дают следующие преимущества:

• Тесты будут проще и понятнее.

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

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

Тесты будут проще и понятнее.

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

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

План сценария

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

• Переменные в шагах схемы сценария отмечены <и>.

• Различные значения для переменных приведены в качестве примеров в таблице.

Переменные в шагах схемы сценария отмечены <и>.

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

пример

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

Особенность — Добавить.

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

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

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

Особые элементы и SpecFlow

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

• Элемент Feature предоставляет заголовок для файла объектов. Элемент функции включает в себя имя и общее описание соответствующей функции в вашем приложении.

  • SpecFlow генерирует класс модульного теста для элемента объекта с именем класса, полученным из имени объекта.

  • SpecFlow генерирует исполняемые модульные тесты из сценариев, которые представляют критерии приемлемости.

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

  • Сценарии имеют имя и могут состоять из нескольких этапов сценария.

  • SpecFlow генерирует метод модульного теста для каждого сценария с именем метода, полученным из имени сценария.

Элемент Feature предоставляет заголовок для файла объектов. Элемент функции включает в себя имя и общее описание соответствующей функции в вашем приложении.

SpecFlow генерирует класс модульного теста для элемента объекта с именем класса, полученным из имени объекта.

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

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

Сценарии имеют имя и могут состоять из нескольких этапов сценария.

SpecFlow генерирует метод модульного теста для каждого сценария с именем метода, полученным из имени сценария.

Несколько этапов сценария

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

• Различные типы шагов начинаются с ключевых слов « Given», «When» или « Then», соответственно, и последующие шаги того же типа могут быть связаны с помощью ключевых слов « And» и « But» .

• Синтаксис Gherkin допускает любую комбинацию этих трех типов шагов, но сценарий обычно имеет отдельные блоки операторов Given, When и Then .

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

• Шаги сценария являются основным способом выполнения любого пользовательского кода для автоматизации приложения.

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

• Соответствие выполняется во время выполнения, поэтому сгенерированные тесты могут быть скомпилированы и выполнены, даже если привязка еще не реализована.

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

Различные типы шагов начинаются с ключевых слов « Given», «When» или « Then», соответственно, и последующие шаги того же типа могут быть связаны с помощью ключевых слов « And» и « But» .

Синтаксис Gherkin допускает любую комбинацию этих трех типов шагов, но сценарий обычно имеет отдельные блоки операторов Given, When и Then .

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

Шаги сценария являются основным способом выполнения любого пользовательского кода для автоматизации приложения.

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

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

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

Теги

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

• Если поддерживается модульным тестом, SpecFlow генерирует категории из тегов.

• Сгенерированное имя категории совпадает с именем тега, но без начального @.

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

Если поддерживается модульным тестом, SpecFlow генерирует категории из тегов.

Сгенерированное имя категории совпадает с именем тега, но без начального @.

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

Фоновые элементы

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

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

• SpecFlow генерирует метод из фоновых элементов, который вызывается из всех модульных тестов, созданных для сценариев.

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

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

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

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

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

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

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

• Поэтому рекомендуется выбрать уникальный и описательный параметр в качестве первого столбца в наборе примеров.

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

• SpecFlow выполняет замену заполнителя как отдельную фазу перед сопоставлением привязок шага.

• Реализация и параметры в привязках шагов, таким образом, не зависят от того, выполняются ли они посредством прямого сценария или схемы сценария.

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

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

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

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

Поэтому рекомендуется выбрать уникальный и описательный параметр в качестве первого столбца в наборе примеров.

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

SpecFlow выполняет замену заполнителя как отдельную фазу перед сопоставлением привязок шага.

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

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

Комментарии

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