Эффективное выполнение сценариев BDD в Cucumber - PullRequest
1 голос
/ 26 октября 2019

Я начал использовать Selenium + BDD Cucumber и обнаружил, что эти две технологии прекрасно работают вместе. Я немного обеспокоен подходом к тому, что можно улучшить гораздо больше, если бы Cucumber предлагал аннотации BeforeAll и AfterAll, чтобы добиться более быстрой проверки в определенных областях с большей детализацией. Скажем, например, что я хотел написать этот сценарий (я специально делаю это просто, чтобы показать свою точку зрения)

Scenario Outline: The customer can update their details
Given I am logged in the platform
And I navigate to my details page
When I update "field" in my details
And Save
I should see the "field" updated
Example:
 |field   |
 |name    |
 |surname |
 |address |

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

Можно использовать @Before, но мало что изменится, потому что эти действия будут выполняться в любом случае каждый раз (а также я не совсем уверен, что это правильный путь в BDD).

Некоторые людиПредлагаем чередовать проверки для каждого поля в серии «Когда / Тогда», что, по-видимому, противоречит основным принципам BDD. Также в этом конкретном случае это означает, что 3 сценария будут сжаты в одном, и если клиенту не удастся обновить поле имени, другие не будут выполнены, давая мне проходной балл 0%, хотя это может быть 66% (при условии, что дляДля простоты у нас есть только 1 сценарий, а два других поля успешно обновлены). Более того, если в обновлении имени есть ошибка, а также в обновлении адреса, я буду знать о проблеме только в первом и понимать о другом только тогда, когда шаги «обновления имени» будут успешными.

A BeforeAll, вероятно, решит проблемупроблема, но это не доступно в огурце.

Чего я хотел бы добиться, так это выполнить серию шагов, чтобы перейти на определенную страницу, а затем выполнить тесты для каждого поля (или с другим уровнем детализации) и выполнить их все в «когда ясделайте это, тогда я должен увидеть это ... »так, чтобы, если что-то не получалось, я знал, что терпит неудачу и что проходит, но, по крайней мере, я уверен, что все было покрыто и не пропущено, потому что предыдущие шаги не сработали.

Извиняюсь за длинный пост, но я надеялся объяснить свое мнение как можно лучше. Не уверен, понятно ли это или имеет смысл вообще.

Спасибо за ваши ответы

1 Ответ

1 голос
/ 26 октября 2019

Ограничение одним сценарием на поле слишком жесткое для BDD. Мне нравится думать о сценарии как об отдельном поведении, связанном с утверждением, которое гарантирует, что поведение функционирует. Было бы целесообразно проверить, что все поля обновляются, если только группа полей не может быть изолирована как отдельное поведение, например, изменение вашего адреса электронной почты должно отправить подтверждение. Это должен быть отдельный сценарий от факта обновления поля электронной почты.

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

Scenario: The customer can update their details
    Given I am logged in the platform       
    And I navigate to my details page
    When I update my details with:
        | Field   | Value        |
        | Name    | Bob          |
        | Surname | Jr           |
        | Address | 123 Smith St |
     And Save
     Then my details should be:
        | Field   | Value        |
        | Name    | Bob          |
        | Surname | Jr           |
        | Address | 123 Smith St |
...