Несколько сценариев в файле характеристик спецификации?

Question

После того, как получил более комфортно в Behavior-Driven Developement с помощью SpecFlow, мне было интересно, о том, несколько сценариев для одной и той же функции следующим образом:

Register.feature

Feature: Register a new user 
    In order to use the system, 
    one must register with the system 
    so that one gets authorized and may login 

Scenario: Register a new user using valid credentials 
    Given I am on the registration page 
    When I have entered my desired username "UserName" and password "password" 
     And I have confirmed my password "password" 
     And I click the register button 
    Then I shall get confirmation that I am now a registered user 

Помимо того факта, что мой сценарий, возможно, слишком толстый, необходимо также проверить другие сценарии в процессе регистрации, такие как:

• Введите имя пользователя слишком коротка
• Входной пароль слишком короткий
• ввода пароля не содержит номера
• Введите пароль не совпадает с паролем подтверждения

Просто имя немного. Я прочитал о тегах, используя SpecFlow Feature файл, так что я мог бы, возможно, сделать следующее:

@shorterPasswordProvided 
Scenario: Register a user using a password that is too short 
    Given I am on the registration page 
    When I have entered my desired user name 
     And I have provided a password that is too short "allo" 
     And I click the Register button 
    Then I shall get an error message which mentions about the password minimum length 

@noCredentialsAtAll 
Scenario: Register a user using no credentials at all 
    Given I am on the registration page 
    When I click on the Register button with no credentials entered 
    Then I shall get an error message that says I have to fill all required fields in 

Затем, используя [BeforeScenario("myTag")] должен сделать трюк.

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

Правильно ли я понял, или я здесь в тумане?

Я слишком далеко?

Я что-то упустил?

Все ли «слишком короткий пароль», «никакие учетные данные» не рассматриваются как разные сценарии использования, или они что-то еще, что может помещаться где-то еще в коде, например, само устройство тестирует?

Я имею в виду, что все эти сценарии относятся к функции «Регистр», и поэтому они должны быть определены в одном и том же файле Feature.Feature SpecFlow, правильно?

Answer 1

Хорошо, у вас есть несколько вопросов, так что я буду работать через них:

Затем, используя [BeforeScenario ("MyTag")] следует сделать трюк.

Атрибут hook BeforeScenario используется для запуска кода перед выполнением сценария. Он часто используется для настройки среды для сценария (например, заполнение тестовой базы данных соответствующими данными); если используется для этой цели, то использование AfterScenario также может использоваться для очистки результата BeforeScenario.

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

Если я вас правильно понял, вы хотите, чтобы иметь возможность использовать тег, чтобы контролировать, когда шаг в сценарии можно запустить/не работай , Это невозможно с атрибутами hook SpecFlow; есть крючок BeforeStep, но это позволяет вам выполнять код только до запуска шага, но это не позволяет игнорировать этот шаг.

ли все «слишком короткий пароль», рассмотренные различные сценарии использования, «не предоставленные полномочия» или нет, они что-то другое, что может только поместиться где-то в коде, как блок сами тесты?

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

Как для сценария:

When I have entered my desired username "UserName" and password "password" 

Вместо этого, используйте:

When I enter my username "UserName" 
And I enter my password "password" 

Делая это, вы будете иметь возможность повторно использовать «Когда я ввожу свой пароль» в " Зарегистрируйте пользователя с слишком коротким паролем ". Это приводит меня к:

And I have provided a password that is too short "allo" 

Нет необходимости в отдельном шаге, в котором указано, что пароль слишком короткий. Просто повторно:

When I enter my password "allo" 

По той же причине не следует использовать:

When I click on the Register button with no credentials entered 

просто повторно:

When I click on the Register button