Огурец - Как структурировать свои тестовые шаги?

Question

В настоящее время я изучаю огурец, и в очень простом тесте у меня возникли некоторые сомнения: «Как лучше организовать мои StepClasses.

Это мой .feature:

Feature: How many potatoes have in the sack

Scenario: I put one potato in the Bag
    Given the bag has 10 potatoes
    When I put 1 potato
    Then I should be told 11 potatoes

  Scenario: I remove one potato from the Bag
    Given the bag has 10 potatoes
    When I remove 1 potato
    Then I should be told 9 potatoes

И мой StepClass:

открытый класс Stepdefs {

private Integer potatoesInTheBag;

@Given("^the bag has 10 potatoes$")
public void the_bag_has_10_potatoes(){
    this.potatoesInTheBag=10;
}

@When("^I put 1 potato$")
public void i_put_one_potato(){
    this.potatoesInTheBag = potatoesInTheBag + 1;
}

@Then("^I should be told (\\d+) potatoes$")
public void i_should_be_told_potatoes(int potatoes) throws Exception {
    assertEquals(potatoesInTheBag.intValue(),potatoes);
}

@When("^I remove 1 potato$")
public void i_remove_one_potato(){
    this.potatoesInTheBag = potatoesInTheBag - 1;
}

}

Этот пример работает нормально, но i_remove_one_potato () должен остаться здесь или на другом шагекласс? Другой вопрос, если я хочу использовать план сценария, как бы я это сделал в этом случае? Потому что ответы будут другими, хотя картошка добавлена ​​/ удалена будет одинаковой. Существуют хорошие практики, которые направляют этот процесс структурирования вашеготесты на огурец?

Thx

Answer 1

Поскольку шаг относится к тестируемому сценарию, было бы хорошо найти шаги в одном файле класса шагов. и для схемы сценария это может быть как: Добавить / удалить картофель из сумки.

: использовать переменные в сценарии, как Учитывая, что сумка имеет "10" картофеля вместо того, который вы используете, это поможет в долгосрочной перспективе.

Answer 2

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

Тем не менее, мне повезло с соотношением 1: 1 между функциями и этапами. Мне нравится иметь один шаг def для обслуживания одного файла объектов и избегать повторного использования шагов в качестве основной стратегии для хранения кода DRY (для этого предназначены объекты страницы!). Иногда имеет смысл повторно использовать шаг (например, учитывая, что я вошел в систему), но мой опыт показывает, что это приводит к созданию этих больших библиотек с очень маленькими атомарными шагами, которые трудно найти, трудно использовать повторно, и гони корнишон до крайности.

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

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

Например, наброски, вы должны быть в состоянии сделать что-то вроде

Scenario Outline: I add/remove potatoes from bag
Given the bag has <initial> potatoes
When I <add_remove> <delta> potatoes
Then I should be told <outcome> potatoes
Examples:
| add_remove | initial | delta  | outcome |
| add        | 10      | 1      | 11      |
| add        | 10      | 10     | 20      |
| remove     | 10      | 1      | 9       |
| remove     | 10      | 10     | 0       |

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

Некоторые мысли! Удачи!