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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BDD Практики

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

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

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

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

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

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

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

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

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

Agile BDD

При разработке программного обеспечения Agile используется метод 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Красный - написание теста, который не удался.

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

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

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

Этапы процесса 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

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

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

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

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

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

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

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

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

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

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

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

Принятие TDD

TDD против BDD

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

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

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

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

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

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

Решением всех этих проблем является развитие, управляемое поведением. Он развился из установленных гибких практик и призван сделать их более доступными и эффективными для групп, новичков в гибкой доставке программного обеспечения. Со временем 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

Преимущества использования Specification by Example -

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

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

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

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

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

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

Применение SbE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Три Амигоса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Анти-шаблон Проблемы
Нет сотрудничества
  • Много предположений

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

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

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

Не знаю, когда код закончен
  • Трудно поддерживать тесты

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

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

Слишком подробные или слишком ориентированные на пользовательский интерфейс примеры
  • Трудно поддерживать тесты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Приготовься.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приготовься

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

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

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

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

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

инструменты

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

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

  • Cucumber

  • SpecFlow

  • Fitnesse

  • JBehave

  • Concordion

  • Behat

  • жасмин

  • Приправы

  • Speclog

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

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

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

  • Cucumber (Рубиновый каркас)

  • SpecFlow (.NET Framework)

  • Вести себя (Python Framework)

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

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

  • Салат (Python Framework)

  • 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 позволяет командам разработчиков программного обеспечения описывать, как программное обеспечение должно вести себя в виде простого текста. Текст написан на понятном для бизнеса, предметно-ориентированном языке и служит в качестве документации, автоматизированных тестов и помощи в разработке, все в одном формате. Вы можете использовать более сорока различных разговорных языков (английский, китайский и т. Д.) С Cucumber .

Cucumber - Основные характеристики

Ключевые особенности Cucumber следующие:

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

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

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

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

SpecFlow

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

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

Вести себя

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

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

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

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

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

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

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

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

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

Салат

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

Concordion

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

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

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

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

  • C # ( Concordion .NET)

  • Python (Py Concordion )

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

Развитие, управляемое поведением - Cucumber

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типичный приемочный тест на Cucumber

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Работа Cucumber

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаги по составлению карт

Реализация Cucumber

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

Рубин / JRuby Рубин / JRuby
JRuby JRuby (используя Cucumber -JVM)
Джава Джава
Groovy Groovy
СЕТЬ .NET (используя SpecFlow)
JavaScript JavaScript
JavaScript JavaScript (с использованием Cucumber -JVM и Rhino)
Clojure Clojure
Gosu Gosu
<span class = Луа "/> Lua
PHP PHP (используя Behat)
Jython
C ++
Tcl Tcl

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

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

Рубин на рельсах Рубин на рельсах
<span class = Селен "/> Selenium
PicoContainer PicoContainer
<span class = Spring Framework "/> Spring Framework
<span class = Ватир "/> Watir

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

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

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

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

Против

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

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

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

Особенность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • сценарий

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

  • Фон

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

  • Примеры

  • "" "(Док Док)

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

  • @ (Теги)

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

  • *

Особенность

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

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

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

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

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

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

feedback_when_entering_invalid_credit_card_details.feature

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

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

Описания

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

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

сценарий

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

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

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

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

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

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

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

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

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

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

пример

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

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

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

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

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

пример

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

  • Учитывая, что у меня есть 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии

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