Корнишон - поддержание состояния между сценариями

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

Scenario: a
    Given that the app is open
    When I open a certain dialog
    Then it has a thing somewhere

Scenario: b
    Given that the dialog from 'a' is open...

# Imagine here a long chain of scenarios, each depending on the previous

Scenario: n
    Given that the previous 'n' steps have all completed....

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

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

Какая здесь лучшая практика?

Должен ли я переписать один очень длинный сценарий?

Я уже использую «объект страницы», чтобы большая часть моего кода не попадала в определения шагов - следует ли кодировать шаги как отдельные вызовы, которые можно повторно использовать в более поздних сценариях?

Я использую Cucumber в Javascript.


javascript cucumber cucumberjs gherkin
person Lee Goddard    schedule 31.03.2016    source источник
comment
Отвечает ли это на ваш вопрос? корнишоны, могут ли два сценария зависеть друг от друга   -  person Marit    schedule 09.04.2020

Ответы (2)


arrow_upward
1
arrow_downward

В первую очередь, Внимание!

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

И теперь к моему ответу:

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

  1. Сделайте первый сценарий фоном
  2. Превратите первый сценарий в определение шага для использования в нескольких файлах функций.

Для Первого:

Background:
  Given that the app is open
  When I open a certain dialog
  Then it has a thing somewhere

Scenario: a
  Given that the dialog from 'a' is open...

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

Для второго:

Scenario: a
    Given that the app is open
    When I open a certain dialog
    Then it has a thing somewhere

Scenario: b
    Given I have opened the dialogue from a
    And the '<DialogFromA>' dialog is open...
person KyleFairns    schedule 31.03.2016
comment
Я согласен с вами в 99,99% случаев. Я не согласен в 0,01% случаев, когда вы думаете, что можно использовать состояние из предыдущего сценария. Просто мое догматичное мнение. Это состояние требует, чтобы сценарии выполнялись в определенном порядке, а не в сетке. - person Dave McNulla; 31.03.2016
comment
Единственный раз, когда я бы рекомендовал это, - это когда вы все еще разрабатываете определение шага для предыдущего сценария, как такового, когда новый сценарий все еще проходит в CI. В идеальном мире определение шага для предыдущего сценария будет написано, однако может случиться так, что у вас есть младший тестировщик, только что закончивший университет, пишущий файлы, который, возможно, не полностью понимает язык. После того, как определение шага было создано или предыдущий сценарий был преобразован в фоновый, он становится устаревшим и, следовательно, будет изменен на правильный способ выполнения. - person KyleFairns; 31.03.2016
comment
Спасибо, @KyleFairns - я отредактировал вопрос, чтобы попытаться подчеркнуть, что функция имеет очень длинную цепочку сценариев, каждый из которых зависит от своего предшественника. - person Lee Goddard; 01.04.2016
comment
Практическая причина этого - скорость автоматизации браузера. Допустим, у меня есть сценарий, который добавляет продукты в корзину, затем я смотрю, есть ли в корзине два продукта, затем у меня есть сценарий, который проверяет, что если я удалю эти продукты, у меня будет ноль товаров в корзине. Я понимаю, что с точки зрения пуриста лучше всего в сценарии удаления добавить два (используя шаги из первого сценария), а затем удалить их. Однако, если мне нужно запустить сотни тестов, это отстой, и их достаточно, чтобы никто не запускал тесты. - person Jacob Singh; 28.09.2017

arrow_upward
1
arrow_downward

Я бы спросил себя, каково на самом деле поведение всех шагов?

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

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

person Thomas Sundberg    schedule 02.04.2016
comment
Помните, что BDD и Cucumber предназначены для удобочитаемого общения. --- Думаю, это главный козырь, спасибо. - person Lee Goddard; 04.04.2016