Как написать правильный файл функции в огурце

Question

Я пытаюсь изучить огурец BDD, и я пытаюсь написать файл функций для сценария входа с действительными и недействительными именами пользователей. Для действительного пользователя будет зарегистрирован и выйдет, однако для недействительного имени пользователя, пользователю будет предложено снова перейти на страницу входа и попросить ввести правильные учетные данные.

Я хотел бы спросить, можем ли мы иметь как положительные, так и отрицательные сценарии в "Сценарном наброске"? Не могли бы вы помочь мне в написании идеального файла функций для этого простого сценария? Посмотрите на мой код файла функций ( PS, я новичок:))

---

Feature: Login Action 
    Description: This feature will test a LogIn and LogOut functionality


Scenario Outline: Login with valid and Invalid Credentials 

    Given User is on Home Page 
    When User navigate to Login Page
    Then User enters "<username>" and "<password>" 
    And Keeping case as Valid
    Then User should get logged in
    And Message displayed Login Successfully
    Then User enters "<username>" and "<password>" 
    And Keeping case as InValid
    Then user will be asked to go back to login page
    And Provide correct credentials

Examples: 
        |username|password|Case|
        |[e-mail]|12345|Valid|
        |[e-mail]|dfsd2|InValid|


Scenario: Successful logout from application 

    When user logs out from application 
    Then Message displayed Logout successfully 
    And Browser quit by driver

Answer 1

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

Тем не менее, важно понимать, что данные "Given/When/Then" (в их самой основной сути) эквивалентны традиционным трем этапам системного теста: "Arrange/Act/Assert", следовательно:

Дано: привести систему в известное состояние

Когда: Командуйте системой (что вы хотите проверить)

Тогда: Утверждайте, что результат был тем, что вы ожидали.

Это оно! (конечно, BDD гораздо больше, но это основы исполняемой спецификации)

Given User is on Home Page не приводит систему в известное состояние, но Given I am registered есть Хотя этого может быть недостаточно, чтобы заявить об этом, потому что, как только вы поймете причины и сценарии, вы быстро поймете, что в качестве примера вы упускаете что-то более конкретное.

Перефразируя предыдущий ответ:

Given I am registered -> настроить пользователя (но имеет ли значение кто?) как зарегистрированного в системе (запись в базе данных?), зарегистрированного для чего? это имеет значение для результата?

When I sign in -> Дайте системе команду для входа (кто?) - это может быть сделано через веб-форму или через API (или по телефону?). Имеет ли значение, в какое время вы входите в систему, можете ли вы войти сразу?

Then I should be signed in -> Проверить ответ из веб-приложения, базы данных, сессии? печенье?

Сказав это, вход в сценарии, вероятно, не стоит использовать BDD для решения, так как они так же хорошо определены, как CRUD - анализ практически не требуется.

Answer 2

Scenario: Good sign in
  Given I am registered
  When I sign in
  Then I should be signed in

Scenario: Not registered sign in
  Given I am not registered
  When I sign
  Then I should not be signed in
  And ...

Scenario: Registered with wrong password
  Given I am registered
  When I sign in with a bad password
  Then I should not be signed in
  And ...

Подсказки:

• Сохраняйте вещи простыми
• Не используйте контуры
• Храните детали того, КАК вы делаете вещи вне сценариев
• Есть один сценарий для каждого пути
• 10 простых сценариев лучше, чем один сложный.

Подробности о том, как писать сценарии, подобные этому (в Ruby), можно найти по адресу https://github.com/diabolo/cuke_up/tree/master/features.

Предостережения:

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

Answer 3

"Идеально" - Разве это не так...

Написанный вами ScenarioOutline очень сбивает с толку и, возможно, неверно интерпретирует работу Outline Outline. В основном, вы входите дважды с каждой строкой таблицы примеров, т.е. то же имя пользователя и пароль (строки 3 и 7 в SO). В сценарии все шаги будут повторяться с каждой строкой данных, которую вы предоставляете в примерах. Обратитесь к нескольким доступным учебникам.

Зачем смешивать действительные и недействительные логины? Храните их в отдельных сценариях. Легко следовать.
Переместите выход в отдельный файл объектов. Затем вы можете переместить первые 3 шага сценария входа в фоновый режим. Уменьшает повторение.

У вас возникнут проблемы с проверкой функциональности входа в систему для действительного случая для нескольких данных. Как только действительный пользователь входит в систему, большинство веб-приложений сохраняют учетные данные для входа в файл cookie и т. Д. И т. Д. Поэтому, когда делается новый запрос для страницы входа в систему, он может просто пропустить страницу входа и перейти на домашнюю страницу, скажем, на домашнюю страницу. Затем вы получите NoSuchElementException, когда код селена ищет поле ввода идентификатора пользователя. Таким образом, для действительных случаев вам также необходимо выйти из системы.

@Login
Scenario Outline: Login with valid and Invalid Credentials 

    Given User is on Home Page 
    ....
    ....

@Valid
Examples: 
        |username|password|Case|
        |[e-mail]|12345|Valid|

@InValid
Examples: 
        |username|password|Case|
        |[e-mail]|12345|Valid|

Для запуска случаев валидного входа используйте опцию tags в runner как {"@Login","@Valid"} или если на огурце 2 @Login and @Valid, Для Invalid один заменить на @InValid.