Given-When-Then — это стиль представления тестов — или, как сказали бы его сторонники — определения поведения системы с использованием
SpecificationByExample . Это подход, разработанный
Дэном Нортом и Крисом Мэттсом в рамках развития,
управляемого поведением (BDD).
[1] Это выглядит как структурирующий подход для многих сред тестирования, таких как Cucumber. Вы также можете посмотреть на это как на переформулировку
шаблона четырехфазного теста .
Основная идея состоит в том, чтобы разбить написание сценария (или теста) на три раздела:
- Даются часть описывает состояние мира , прежде чем начать поведение которой нужно указать в этом сценарии. Вы можете думать об этом как о предварительных условиях теста.
- Раздел когда это то поведение, которое вы указываете.
- Наконец, раздел then описывает изменения, которые вы ожидаете из-за указанного поведения.
Поскольку мы говорим об использовании примеров в качестве спецификаций, имеет смысл показать это на примере [2]
Feature: User trades stocks
Scenario: User requests a sell before close of trading
Given I have 100 shares of MSFT stock
And I have 150 shares of APPL stock
And the time is before close of trading
When I ask to sell 20 shares of MSFT stock
Then I should have 80 shares of MSFT stock
And I should have 150 shares of APPL stock
And a sell order for 20 shares of MSFT stock should have been executed
В приведенном выше примере используется Cucumber [3] , который является популярным способом написания BusinessFacingTests, но вы можете использовать стиль Given-When-Then с любым видом тестов. Некоторые люди любят помещать Given-When-Then в качестве комментариев, чтобы отметить неформальные блоки внутри модульных тестов [4] . Я также видел это соглашение, чтобы структурировать неформальную прозу.
При таком подходе обычно видят «и», используемые для объединения нескольких выражений в каждом предложении.
Я охарактеризовал данное как описание состояния предусловия, потому что я так думаю об этом. Однако инфраструктура тестирования интерпретирует данные как набор команд, чтобы привести тестируемую систему в правильное состояние перед выполнением команды when. (Именно поэтому другие соглашения об именах часто называют эту «настройку».) Среды тестирования предоставляют различные методы запросов для команд then — они не должны иметь побочных эффектов.
Хотя стиль Given-When-Then является симптоматичным для BDD, основная идея довольно распространена при написании тестов или спецификации на примере. Месарош описывает модель как четырехфазный тест . Его четыре фазы — «Настройка» («Дано»), «Упражнение» («Когда»), «Проверка» («Затем») и «Срыв» [5] . Билл Уэйк придумал формулировку « Аранжировать, действовать, утверждать» .
Заметки
1: В комментариях к обзору Дэн благодарит Ивана Мура за значительный объем вдохновения в разработке этого.
2: от Пита Ходжсона
3: Или, чтобы быть строгим, он использует Огурец, который является названием DSL Огурца.
4: Тестовые среды имеют тенденцию следовать стилю именования xunit или BDD, последние имеют тенденцию называть методы в стиле Given-When-Then.
5: Срыв не всегда необходим при реализации тестов (особенно, если вы используете Automated Teardown ) и не добавляет особого аспекта спецификации связи на примере. Поэтому разумно видеть, что это отсутствует в стиле BDD.