Приемлемо ли писать тест «Дано, когда, тогда, когда и тогда» на языке «Огурец»?

Это зависит от целевой аудитории функции, как написано. Весьма вероятно, что корнишон, который у вас есть, не был написан заинтересованным лицом (то есть кем-то, кто не является техническим специалистом, но имеет личную заинтересованность в бизнесе и веб-сайте). 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

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

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

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

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

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

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

Scenario: Guest buys a product
  # 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 шагов — это возможность установить неправильное состояние, то есть совершить ошибку интегрирования. Этот набор сценариев имеет гораздо меньшую ценность как набор интеграционных тестов, чем отдельный сценарий. Возможно, вы почти написали серию модульных тестов.

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

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

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

В отдельном моем посте Daniel F нашел эту фантастическую статью. Вот соответствующий раздел:

Шаги Given-When-Then должны отображаться по порядку и не могут повторяться. «Данное» не может следовать за «Когда» или «Тогда», а «Когда» не может следовать за «Тогда». Причина проста: любая отдельная пара Когда-Тогда обозначает индивидуальное поведение. Это позволяет легко увидеть, как в приведенном выше тесте на самом деле рассматриваются два поведения: (1) поиск из панели поиска и (2) выполнение поиска по изображению. В Gherkin один сценарий охватывает одно поведение. Таким образом, должно быть два сценария вместо одного. Каждый раз, когда вы хотите написать более одной пары «Когда-тогда», вместо этого напишите отдельные сценарии. (Примечание: некоторые BDD-фреймворки могут допускать беспорядочные шаги, но это, тем не менее, будет антиповеденческим.)

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

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

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

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

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

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

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

Данное является предварительным условием для установки. Форма «Когда» — это действие (которое может быть бездействием). Форма «Тогда» утверждает.

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

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