CODEWITHSUNDEEP
selenium-webdrivercucumberbddfeature-file
Nit QA
Nit QA

Reputation: 57

How to write correct feature file in Cucumber

I am trying to learn BDD cucumber and i am trying to write a feature file for login scenario with valid and invalid usernames. For valid user will be logged and will logout however for invalid username, the user will be asked to go to login page again and asked to write correct credentials.

I would like to ask, can we have both positive and negative scenarios in "Scenario Outline"? Could you please help me in writing perfect feature file for this simple scenario? Take a look at my feature file code ( PS, I am a beginner :))

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|
        |[email protected]|12345|Valid|
        |[email protected]|dfsd2|InValid|


Scenario: Successful logout from application 

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

Upvotes: 0

Views: 11954

Answers (3)

diabolist
diabolist

Reputation: 4099

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 ...

Tips:

  • Keep things simple
  • Don't use outlines
  • Keep details of HOW you do things out of scenarios
  • Have one scenario for each path
  • 10 simple scenarios are better than one complex one.

You can see details of how to write scenarios like this (in Ruby) at https://github.com/diabolo/cuke_up/tree/master/features.

Caveats:

  • this is just one persons opinion
  • you need to be able to write code to work this way (as you push all the details of how things are done out of cucumber and into helper code).
  • registration is a pre-requisite to sign in

Upvotes: 1

Jon Acker
Jon Acker

Reputation: 31

As pointed out here in an excellent answer - each scenario is essentially one test case and must therefore be clearly separated.

Nevertheless, it's critical to understand that Given/When/Then (in their most basic essence) are equivalent to the traditional three stages of a system test: Arrange/Act/Assert, therefore:

Given: Arrange the system in a known state

When: Command the system (what you want to test)

Then: Assert that the outcome was what you expected.

That's it! (of course there's a lot more to BDD than that - but these are the basics of an executable specification)

Given User is on Home Page is not arranging the system in a known state, but Given I am registered is. Though it might not be enough to state just this, because as soon as you go through the whys and whats of the scenario you'll quickly realize that you're missing something more concrete as an example.

To paraphrase the previous answer:

Given I am registered -> set up the user (but does it matter who?) as being registered in the system (database entry?), registered for what? does it matter to the outcome?

When I sign in -> Give the system the command to sign-in (who?) - this might be done via a web form or via an API (or over the phone?). Does it matter what time you sign in, can you sign in immediately?

Then I should be signed in -> Check response from web app, database, session? cookie?

Saying that, logging in scenarios are probably not worth using BDD to tackle since they are as well defined as CRUD - there's almost no need for analysis.

Upvotes: 1

Grasshopper
Grasshopper

Reputation: 9058

'Perfect' - Ain't no such thing...

The ScenarioOutline you have written is very confusing and possibly a wrong interpretation of how scenariooutline works. Basically you are logging in twice with each row of the examples table ie. same username and password (line 3 and 7 in the SO). In a scenariooutline all the steps will be repeated with each row of data that u provide in examples. Refer to multiple tutorials available.

Why mix up valid and invalid logins? Keep them in separate scenarios. Easy to follow.
Move the logout to a separate feature file. Then you can move the first 3 steps of the login scenario into a background. Reduces repetition.

You are going to have a problem with checking login functionality for the valid case for multiple data. Once a valid user logs in then most web applications store the login credentials in a cookie etc etc. So when a new request is made for login page it might just skip the login page and land up in maybe lets say home page. Then you will get the NoSuchElementException when the selenium code looks for the userid input box. So for valid cases you need to have a logout too.

@Login
Scenario Outline: Login with valid and Invalid Credentials 

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

@Valid
Examples: 
        |username|password|Case|
        |[email protected]|12345|Valid|

@InValid
Examples: 
        |username|password|Case|
        |[email protected]|12345|Valid|

To run the Valid Login cases use the tags option in runner as {"@Login","@Valid"} or if on cucumber 2 @Login and @Valid. For Invalid one replace with @InValid.

Upvotes: 1

Related Questions