0

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|
        |abc@gmail.com|12345|Valid|
        |abc1@gmail.com|dfsd2|InValid|


Scenario: Successful logout from application 

    When user logs out from application 
    Then Message displayed Logout successfully 
    And Browser quit by driver
Grasshopper
  • 8,908
  • 2
  • 17
  • 32
Nit QA
  • 37
  • 2
  • 3
  • 8

3 Answers3

1

'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|
        |abc@gmail.com|12345|Valid|

@InValid
Examples: 
        |username|password|Case|
        |abc@gmail.com|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.

Grasshopper
  • 8,908
  • 2
  • 17
  • 32
  • Thanks very much.. Moving logout to saperate feature file is really great way to simplify the test case. I will try to implement the same and get back to you on the original thread. – Nit QA Jun 01 '18 at 09:25
  • I created two feature files, Login.feature Logout.feature however when i am trying to access the scenarios in once test class i am unable to do so. Could you please let me know how i need to provide details on two feature file in test runner class? My current test runner code looks like this,@RunWith(Cucumber.class) @CucumberOptions( features="Feature", glue={"stepDefinition"}, format = {"junit:Reports\\JUnitXML\\cucumber.xml"}, tags = {"@Login","~@Logout"} ) public class TestRunner { } – Nit QA Jun 01 '18 at 12:40
  • If you want both the feature files to run remove the tag option – Grasshopper Jun 01 '18 at 12:50
  • But lets say i want to run 2 test case from 1st feature file and 1 from second feature file then? – Nit QA Jun 01 '18 at 12:55
  • Add the feature file to the question and mention the requirement. Hard to understand without code – Grasshopper Jun 01 '18 at 12:58
  • Feature file 1:Feature: Login Action Description: This feature will test a LogIn and LogOut functionality @Login Scenario Outline: Login with valid and Invalid Credentials Given User is on Home Page When User navigate to Login Page Then User enters "" and "" # And User enters "abc@gmail.com" and "2454#" And Keeping ""case as Valid Then User should get logged in And Message displayed Login Successfully Examples: |username|password|Case| |abc@gmail.com|sdfsd|Valid| – Nit QA Jun 01 '18 at 13:08
  • Feature file 2:Feature: Logout Action Description: This feature will test LogOut functionality once the user logs in successfully @LogoutTest Scenario: Successfull logout from application Given User is Logged in successfully When user logs out from application Then Message displayed Logout successfully And Browser quit by driver – Nit QA Jun 01 '18 at 13:10
  • I want Login scenario from feature file 1 and logout from feature file 2 – Nit QA Jun 01 '18 at 13:11
  • Sorry. Let me explain. I have two feature files. First file have two scenarios 1. Login 2. GoToaccountpage and second feature file has one scenario 1. @Logout. My problem is, i want to run scenario Login from first file skipping GoToaccountPage and Logout from second feature file. I am getting an error saying , couldnt find Logout scenario. Did you understand now? – Nit QA Jun 01 '18 at 14:37
  • Nothing to be sorry about. Put a "@Login" tag on the login scenario and "@Logout" tag on the logout scenario. Use the tag option on runner as "@Login,@Logout" – Grasshopper Jun 01 '18 at 14:51
  • Have another question. I am having below examples in my feature file, |username|password|Case| |abc@gmail.com|1234|Valid| |abc1@gmail.com2548|InValid| In this case, can i have a code wherein it will select username depending upon the case provided? I tried giving Case as "Valid" but the code ran for both valid and invalid cases. Or this wont possible in cucumber as it will always run tests for both rows? I will have to define two different feature files for valid and invalid cases? Kindly help – Nit QA Jun 04 '18 at 12:21
1
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
diabolist
  • 3,990
  • 1
  • 11
  • 15
  • Thanks buddy. To summarize your commnents i think, cucumber(Gherkin) is all about keeping everything simple and not to complicate it. Its about writing a simple sentence than an entire essay. :) – Nit QA Jun 01 '18 at 09:26
1

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.

Jon Acker
  • 31
  • 6