Тестирование лучших практик возможно в отношении корнишона, но, вероятно, нет - PullRequest
Новая
       94

Тестирование лучших практик возможно в отношении корнишона, но, вероятно, нет

0 голосов
/ 19 декабря 2018

Мы с коллегой спорим о правильном способе тестирования.Я выложу их настолько нейтрально, насколько смогу, и не буду высказывать свое мнение в этом посте.

Это написано в корнишоне.Замените любой псевдокод, который вы хотите. 

Given I am a registered user
When I submit my credentials
Then I can login

Первый случай: 

Given I am a registered user 
    (instantiates the user,
    stores the user to scenario-global memory,
    adds the user to the db with an API endpoint
    stores the API endpoint result to scenario-global memory [200, "Success message"])

When I submit my credentials
    (test the result of the previous step [200],
    fills the credential field(s),
    clicks submit, stores the result to scenario-global memory [200, "Success message"])

Then I can login
    (tests the results of the previous step)

Второй случай: 

Given I am a registered user
    (instantiates the user,
    stores the user in scenario-global memory,
    adds the user to the db, tests the result of the db command)

When I submit my credentials
    (fills the UI credential field(s),
    clicks submit)

Then I can login
    (perform some operation that only a logged-in user could do [see the my profile button/call some api endpoint])

Конфликт состоит в том, может ли шаг Тогда полагаться на результат предыдущей операции.

Ответы [ 2 ]

0 голосов
/ 03 января 2019

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

добавляет пользователя в базу данных с конечной точкой API

- это то, что лучше всего использовать, когда поток register user покрыт хотя бы один раз через пользовательский интерфейс.Смешивание API и пользовательского интерфейса в сценариях может привести к путанице и проблемам с обслуживанием.Правильный DSL должен справиться с этим для вас.

Что касается

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

Каркасы Cucumber-ish действительно используют DI контекста / состояния, именно для этого -выполнение шага совместного использования в текущем экземпляре World.

0 голосов
/ 20 декабря 2018

Это зависит.Прежде всего, в качестве тестера, я бы никогда напрямую не записывал что-то в БД, вместо этого я регистрировал пользователя в UI для тестирования UI или вызывал конечные точки для покрытия сценариев тестирования API.

Кроме того, ИМО, не каждый шаг отвечает за тестирование своего собственного шага, в противном случае нет необходимости в синтаксисе «Тогда» Gherkin.Такой способ написания пользовательских историй делает понятным нетехническим, но деловым людям более понятное представление о тестируемом сценарии.

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

...