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

Question

Мне нужен совет о том, как писать сценарии.Сначала я должен объяснить, что у нас есть архитектура CQRS, в которой команды и запросы являются отдельными API.Мы указываем команды со сценариями Gherkin, которые используются в Specflow для создания тестов.

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

При следующем подходе я пытаюсь использовать как можно больше шагов:

Background: 
  Given I am declarant 'Marieke'

     Scenario: Not allowed to create expense for a bundle that was created by another declarant
     Given the following expense bundles exist
        | declarant | name             | administration    | status        |
        | Lucy      | Trip to New York | Company B.V.      | not submitted |
       When I create an expense for the following expense bundle
        | declarant | name             | administration    | status        |
        | Lucy      | Trip to New York | Company B.V.      | not submitted |
       Then the expense is not created for the expense bundle

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

В следующем подходе я пытаюсь написать сценарий, который будет лучше читаемым и более конкретным:

Background: 
  Given I am declarant 'Marieke'

    Scenario: Not allowed to create expense for a bundle that was created by another declarant
       When I create an expense for an expense bundle that was created by another declarant
       Then the expense is not created for the expense bundle

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

Я много борюсь с обоими вариантами в моих сценариях.Любой совет?

Answer 1

Способ написания сценариев также объясняет ЧТО и ПОЧЕМУ и ничего не говорит о том, КАК все сделано.ЧТО ТАКОЕ требует претензий на расходы и, в частности, то, что вы не можете требовать расходы для кого-то еще.Вы действительно не объяснили, ПОЧЕМУ это важно, вы можете сделать это в преамбуле функций.Сценарий не должен наплевать на то, КАК пакеты расходов.Другие проблемы со сценариями заключаются в том, что язык кажется немного неуклюжим.Опять же, вы можете использовать преамбулу, чтобы объяснить, что такое пакет расходов.Так что я бы написал что-то вроде

Feature: Claiming an expense on an expense bundle

Explain what an expense bundle is, including the concept of ownership
Explain what an expense is
Explain why Fred should not be able to claim an expense on Susan's expense bundle

Background:
  Given users Fred and Susan
  And Susan has an expense bundle

  Scenario: Susan claims an expense
    When Susan claims an expense on her bundle
    Then the expense should be approved

  Scenario: Fred claims an expense on Susan's bundle
   When Fred claims an expense on Susan's expense bunlde
   Then the expense should be rejected

Это будет моей отправной точкой, и я буду использовать это для ответа на такие вопросы, как

1. Почему Фред может увидеть связку расходов Сьюзен
2. Должны ли мы уведомить кого-либо (Сьюзен, босс Фреда, Фред), когда Фред пытается завладеть расходом
3. ...

Когда повторное использование определения шага уклонения не имеет значения, ЕСЛИ вынапишите ваши определения шагов правильно.Правильный способ написания определений шагов - сделать каждый отдельный вызов вспомогательного метода.Таким образом, определения шагов сводятся к выполнению одной единственной функции - переводу бизнес-языка в вызов.Таким образом, не имеет значения, если шаг используется только один раз (большинство не используется), потому что его написание тривиально.

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

Answer 2

Использование сценариев Контуры могут быть решением с наиболее многократно используемым кодом (шаги).Я думаю, что мне не хватает некоторого контекста точной функциональности, но это может дать вам представление о том, как к этому подойти.Недостатком этого является то, что при наличии большого количества параметров в сценариях может быть не так просто читать и интерпретировать результаты теста, поэтому это также зависит от вашей цели и того, кто (тестировщик, бизнес, разработчик) будет создаватьи интерпретация результатов теста.Больше информации о набросках сценария https://www.toolsqa.com/cucumber/data-driven-testing-using-examples-keyword/

Abstract Scenario: Don't allow expense creation on bundle of other declarant
Given the expense bundle exists <declarant creator> 
When I create an expense for the bundle <expense creator>, <bundle administration>
Then I expect the bundle expense to be <expected>
Examples:
| bundle creator    | expense creator       | bundle administration | status        | expected    |
| Lucy              | Marieke               | Company B.V.          | Not submitted | Not allowed |
| Marieke           | Lucy                  | Company 2 V.          | Not submitted | Not allowed |
etc..

И счастливых потоков

Abstract Scenario: Allow expense creation for blabla
Given the expense bundle exists <declarant creator>, <bundle administration> 
When I create an expense for the bundle <expense creator>, <bundle administration>
Then I expect the bundle expense to be <expected>
Examples:
| bundle creator    | expense creator       | bundle administration | status        | expected    |
| Lucy              | Lucy                  | Company B.V.          | Not submitted | Allowed     |
| Lucy              | Lucy                  | Company B.V.          | Not submitted | Allowed     |
etc..

Answer 3

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