Пытаюсь усовершенствовать свои сценарии с огурцом

Я считаю, что лучше всего разбивать функции на различные части (в данном случае сценарии).

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

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

Лучшая практика в этом контексте отстаивает меньшие участки кода. Если эти тесты начнут повторяться (СУХИЕ, не повторяйтесь), вы можете начать их рефакторинг (возможно, с Background)

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

Набросок сценария может сделать ваш тест как подробным, так и кратким. В следующем примере с первого взгляда очевидно, что ресурсы B, C и D имеют одинаковую политику, а ресурс A - другой:

Scenario Outline: A user cannot access an unauthorized resource
    Given I am a user without access to <resource>
    When I navigate to reports
    Then I do not see the <resource> section

    Examples:
        | resource |
        | B        |
        | C        |
        | D        |


Scenario: A user that cannot access A
    Given I am a, user without access to A
    When I navigate to reports
    Then I see the A header
    And I see error message under A stating the user does not have access
    But I cannot click on A's header

Я бы заменил A B C или D чем-то более читаемым, просто подумайте, что ваша бабушка должна понимать это определение, она не поймет, что означают A B C D. так давай скажем так

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

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

Просто попробуйте присоединиться к этим A B C D во что-то значимое, например, название группы, уровень n, команду и т. Д.

тогда вы будете использовать TestUnits для каждого из элементов: A B C D, если вы