Gherkin для проверки правильности значения

Question

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

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

Так, например, сценарий может быть записан следующим образом:

Given I have a saved record with code 'X'. 
    When I change the code to 'Y' 
    Then the modified code is displayed in the dialog 
    When I save and re-open the record 
    Then the modified code is still displayed in the dialog 

Однако, от того, что я прочитал, многократные Когда-Then положение в сценарии следует избегать.

Я предполагаю, что это может записать следующим образом:

Given I have a saved record with code 'X'. 
    When I change the code to 'Y' 
    Then the modified code is displayed in the dialog before the record is saved 
    And the modified code is displayed in the dialog after the record is saved and re-opened. 

Примечание: Из-за автоматизированных тестеры не будучи хорошо знакомы с приложением, Тестовые корнишона должны быть прописаны с тестовыми данными и не декларативной в природе.

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

Заранее благодарим за любую помощь, которую вы можете предоставить!

Answer 1

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

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

Но, на мой взгляд, нет ответа на один размер. Факторами, которые необходимо учитывать, являются:

1. Сколько времени вам нужно посмотреть?
2. Наборы навыков, доступных для вас
3. Как долго ваши испытания принимают для запуска
4. Вы используете сценарии Огурец писать спецификации и автоматизировать тестирование или просто написать автоматизированные тестовые сценарии?

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

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

И, наконец, лучшего способ справиться с этим было бы разделить тест на две части, и макет из начальных шагов, с тем, что во втором тесте вы можете просто сделать утверждение, что он работал при повторном открытии Это. Однако, если у вас нет доступных наборов навыков, чтобы сделать это легко, если это действительно достаточно большой вопрос, чтобы посмотреть? И точно так же, сколько времени у вас есть, это достаточно большая сделка, на которую стоит потратить время? Тем не менее, одна большая вещь, которую следует учесть, заключается в том, что в будущем ваши тестовые системы появятся очень много. Если это будет возможно, стоит потратить время ...