Допустимо ли писать тест "Учитывая, когда тогда, когда" в "Орглинке"?

Ответ 1

Это зависит от целевой аудитории функции как написано. Кажется весьма вероятным, что у огурца, который у вас там есть, не было написано с участием заинтересованного лица (т.е. Кто-то не-techie, но заинтересовался бизнесом и веб-сайтом). BDD действительно о разговоре о требованиях и ожиданиях - и Gherkin - это инструмент, который дает стандартный/узнаваемый способ, чтобы каждый мог читать, что вы можете писать требования и ожидания; таким образом, чтобы выполнять автоматические тесты для разработчика и, возможно, тестировать скрипты для тестера.

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

Scenario: Should be able to successfully register on website
    Given I am new to the website
    And I want to register for a user account
    When I go to the registration form
    And I complete all the required registration details correctly
    Then I will be registered on the website
    And I will be automatically logged in

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

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

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

Ответ 2

Да, более одного цикла When/Then соответствует сценарию Gherkin, когда сценарий реального мира вызывает его.

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

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

Scenario: Guest adds a product to their shopping cart then checks out
  # This scenario starts with the user not logged in, which doesn't require a step
  Given there is a product named "Elliptical Juicer"

  When I go to the product page for "Elliptical Juicer"
  And I add the product to my shopping cart
  Then I should see 1 product in my shopping cart

  When I request to check out
  Then I should see the account creation form

  When I create an account
  Then I should see the checkout form with 1 product, "Elliptical Juicer"

  When I check out
  Then I should see the checkout success page with 1 product, "Elliptical Juicer"
  And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer"

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

Существует несколько причин, почему этот сценарий лучше всего пишется с несколькими циклами When/Then:

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

  Аналогично, Then I should see the account creation form и Then I should see the checkout form with 1 product, "Elliptical Juicer" могут тестировать важные требования в точках сценария, в которых естественно их протестировать.

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

  Given there is a product named "Elliptical Juicer"
  When I go to the product page for "Elliptical Juicer"
  And I add the product to my shopping cart
  And I request to check out
  And I create an account
  And I check out
  Then I should see the checkout success page with 1 product, "Elliptical Juicer"
  And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer"
  

  And I create an account приходит как сюрприз, не так ли? Это требует от читателя сделать вывод о том, что гостевому пользователю предлагается создать учетную запись во время проверки. Это яснее сказать так явно, как в первой версии сценария, который я дал.

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

  Scenario: Guest adds a product to their shopping cart
    Given there is a product named "Elliptical Juicer"
    When I go to the product page for "Elliptical Juicer"
    And I add the product to my shopping cart
    Then I should see 1 product in my shopping cart
  
  Scenario: Guest with a product in their shopping cart attempts to check out
    Given I have a product in my shopping cart
    When I request to check out
    Then I should see the account creation form
  
  Scenario: Guest creates an account
    Given I have a product named "Elliptical Juicer" in my shopping cart
    And I am on the account creation form
    When I create an account
    Then I should see the checkout form with 1 product, "Elliptical Juicer"
  
  Scenario: Newly registered user checks out
    Given I am a user
    And I have a product named "Elliptical Juicer" in my shopping cart
    And I am on the checkout form
    When I check out
    Then I should see the checkout success page with 1 product, "Elliptical Juicer"
    And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer"
  

  Это ужасно! Во-первых, ни один из сценариев не является тем, что заинтересованный субъект мог бы рассматривать как сценарий. Во-вторых, при изменении одного из промежуточных состояний необходимо будет изменить два шага: шаг, который устанавливает промежуточное состояние и шаг Given, который устанавливает промежуточное состояние для следующего сценария. Каждый из этих шагов Given - это возможность установить неправильное состояние, т.е. Сделать ошибку интеграции. Этот набор сценариев имеет гораздо меньшую ценность как набор тестов интеграции, чем один сценарий. Вы, возможно, почти написали серию модульных тестов.

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

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

Ответ 3

Я бы сказал, нет.

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

Вам нужно определить, что тестирует ваш тест (что должно быть одно), читающий ваш тест

• это может быть проверка проверки формы.
• Это может быть регистрация.
• это может быть тест пользовательской панели.

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

Ответ 4

Я бы тоже сказал "Нет".

В отдельной посте шахты Даниэль Ф нашел эту фантастическую статью. Вот соответствующий раздел:

Данные-Когда-Тогда шаги должны появляться в порядке и не могут повторяться. Дано может не следовать "Когда" или "Затем", а "Когда не может следовать" "Затем". Причина проста: любая одиночная пара "Когда-то" обозначает индивидуальное поведение. Это позволяет легко увидеть, как в вышеприведенном тесте есть два способа поведения: (1) поиск из строки поиска и (2) выполнение поиска изображений. В Охотнике один сценарий охватывает одно поведение. Таким образом, должно быть два сценария вместо одного. Каждый раз, когда вы хотите написать более одной пары "Когда-Тогда", вместо этого напишите отдельные сценарии. (Примечание. Некоторые рамки BDD могут допускать неупорядоченные шаги, но тем не менее они будут анти-поведенческими.)

https://automationpanda.com/2017/01/30/bdd-101-writing-good-gherkin/

Ответ 5

Я бы тоже сказал "Нет".

Данное условие является предварительным условием для установки. Когда это действие (которое может ничего не делать) Утверждается форма Then.

Если вам нужно больше действий, отмените тест.

Это станет намного более полезным после первого. Тогда не удалось локализовать проблемы.