Here are three example BDD statements that should help explain my question:
Scenario: User logs in
Given I am on the login screen
When I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
Then I should see the login successful page
Scenario: User buys a product
Given I am logged into the system using username "myUsername" and "myPassword"
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory
vs
Scenario: User buys a product
Given I am on the login screen
And I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory
So scenario 1 above is fine, but which is best out of statement 2 and 3. Statement 2 reads nicely and more concisely. But my step definition for
"Given I am logged into the system using username "myUsername" and "myPassword""
will need to repeat calls to the Page Objects (or equivalent) that scenario 1 called... seems like more dev effort.
So really just wondering if anyone knows which is best practise. I have searched online and found the following document:
http://docs.behat.org/guides/1.gherkin.html
This suggestions scenario 2 is best, but then writes: "Authenticate a user (An exception to the no-interaction recommendation. Things that “happened earlier” are ok)" which kinda lends itself to scenario 3.
Cheers,
Charlie
Here is my review of the scenarios you've written.
Scenario 1
Scenario: User logs in
Given I am on the login screen
When I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
Then I should see the login successful page
Pros : You are correctly using the Given, When and Then statements. In this scenario the Given sets the initial state of the system, the When indicates actions which a user will take and the Then details the assertions made to verify the behaviour of the system.
Cons : Whilst what you have written will work, the problem you have is that this test is brittle. If your company was to mandate that a time-dependent security token also had to be specified during log-in (for example), you'd have to add another step to input this additional field. However if you rewrote this step to be declarative e.g.
Given I am on the login screen
When I submit valid log-in criteria
Then I should see the login successful page
Then if the log-in process was changed, you would only need to alter the code, the scenario would remain the same.
Scenario 2
Scenario: User buys a product
Given I am logged into the system using username "myUsername" and "myPassword"
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory
Pros : Same as above.
Cons : Again the test is brittle as it's imperative i.e. you are specifying the exact log-in credentials and a specific product. I'd re-write this as:
Given I am logged into the system
When I purchase a product
Then I should have that product in the product inventory
You can save the product specified in the "When" step in ScenarioContext.Current. You would then be able to re-use this value in your "Then" step to assert that it is present in the product inventory.
Scenario 3
Scenario: User buys a product
Given I am on the login screen
And I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory
Cons : This is the worst of your scenarios as you are incorrectly using the Given statement. A Given statement should be used to define an initial system state for the test, so in this case "Given I am on the login screen" is a correct use, but "Given I enter the valid username "myUsername"" is an incorrect use. It is incorrect as it is indicating a user action, hence it should be covered by a When. Yes, you can use a Given to perform the same programmatic steps as a When, but it doesn't make it right!
I'd change this scenario to the version I suggested in Scenario 2.
Firstly, there is absolutely nothing in Gherkin that prevents you from writing specifications in any order, you can even produce compound specifications such as
Given ...
When...
Then ...
When ...
Then ...
Given ...
When ...
Then ...
So why would you want to do this?
Well first lets consider a fourth variant of your scenario
Scenario: User logs in and buys a product
Given I am on the login screen
When I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
Then I should see the login successful page
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory
This is of course just a compound of 1 and 2. You might have written this because you had finished testing login and wanted to quickly write and test buying a product. You already have the code for the Bindings in scenario one and now simply need to write the bindings for scenario two. You might consider this your simplest pragmatic change, and you will refactor it later. This nothing wrong with it, running the tests could be quicker, but also its not exactly ideal.
Now imagine that due to the nature of your shop you have written many tests that test different buying processes. We could be testing what happens when you add the same item again to your basket, or if you try to buy something out of stock, or different checkout experiences if you want special delivery. In fact your shop is so successful that you need to be really secure on the web and change your login process. Unfortunately you now have those three lines
Given I am on the login screen
When I enter the valid username "myUsername"
And I enter the valid password "myPassword"
repeated throughout your scenarios. If we accidentally break our login process with some bad code, suddenly all of our tests fail. You are presented with a wall of red and can't really narrow down where to start looking at the problems. Because we are dependant on logging in before we run our scenario we cannot isolate login from purchase.
This really is the difference between a Given and a When. A When is there to indicate that we are performing a process, a Given is a means of directly affecting the run time environment so that we simply have the correct state. It's basically the difference between
//Given
isLoggedIn = true
//When
if CheckValidPasswordForUser(user, password)
isLoggedIn = true
The Given has no way to fail.
So coming all the way back to your original question,
Can you re-use Givens as Whens? Yes, but it in the long term it will confuse you.
But if you ask Can you re-use Whens as Givens? then I would definitely advise you not to. This will hide the fact that something that could break is being tested.
Finally there is one other thing to consider and that is the domain of your specification. Dan North has a really good article on this Whose Domain is it anyway?, but the general gist as applied to your example here is that when you are looking at product buying you can simply write
Given I am logged in as a customer
or
Given I am logged in as an administrator
because the username and password parts are to with login and not products, and that way you are protected from re-writing all your scenarios when you change your login process to use something else.
Related
I am required to create a Java Script but unable to figure on how to proceed as I don't have that much of coding idea in OIM, can someone assist(below I have mentioned the scenario)
Scenario:
In OIM User Attribute Page, there is a User Field: 'Job Code' now we have experienced that there are some issues we are facing.
From the trusted source we are getting the correct data but as soon as it reaches OIM for few users we are getting random incorrect value. Value should be numbers (123456) which is present in the Database too and valid but for few we are receiving values like E?401#q something like this.
We are required to place a check to find users who are having these invalid Job Code entry.
Once detected, we need to trigger a email to the concerned team based on the User Type (Employee or Contractor) for employee it should trigger an email to a respective team and for Contractor we have to trigger to a different team to take action.
So, I believe we have to place two conditions here, can someone assist.
If you believe it only happens during trusted source reconciliation, then you can create Post-Process Handler on User Create/Modify operation to check the value which was posted into the DB as a result of recon event.
From this handler you can do all the things you need to do: mailing, fixing, etc.
For notification purposes I'd recommend to use built-in NotificationService, though it might be bit daunting, if you have little experience in OIM development. As an alternative you can do java mailing.
If you are not sure about the moment, when this "spoiling" happens, you can create a scheduled task, to be executed periodically, which will check JobCode values, to report invalid ones.
I am trying to convert Selenium test to Gherkin. Is there way to implement if statements in Gherkin?
Example : assume the code is written in the below format. I am just writing description as below. Please understand the part after double slash is the actual Selenium code:
// launch the application
// login to application
// navigate to page
String str;
if(str== "XYZ")
{
// verify title
}
//verify text field 1
//verify test field 2
//verify select box
For this I am trying to write code in Gherkin as follows
Given user launches the application
When user login with valid credentials
and navigate to required page
When String str is "XYZ"
Then verify title
And verify text field 1
And verify test field 2
And verify select box
but this code is incorrect because if the str is not equal to "XYZ" we want that title should not be verified but other verification like text field1,2 and select box should be verified.
You don't implement if in Gherkin.
Gherkin is about communication and those you want to communicate with, non coders, don't know what an if statement is. They don't care either.
The solution? Two scenarios to cover both cases.
Ideally, this level of detail would not be in your Gherkin scenario. The best approach is describe business use cases, not low level details. This is what Gherkin is designed for: communicating with non-technical stakeholders so that you can work out if you are building the right thing in the first place. Here is what I would write:
Given the user is logged in
And the user is on the required page
When they enter data that requires the optional fields to be validated
And they enter invalid data in the optional fields
Then the form shows an error on the optional fields
The low level details don't matter (that the string is specifically "XYZ" or that it is the title field is not important), so these should be hidden in the step definition and/or unit tests.
In order to continue to check the other fields, you can just add another step after this:
When they enter invalid data in all of the other fields
Then each other field has an error message attached to it.
Again, there is no need to specify the actual fields, or separate them into their own steps. The idea is to express the high level business value of the scenario, i.e. that the form is validated when it should be.
The advantage to keeping things high level is that when the form changes (as it eventually probably will), then this scenario can remain untouched. Which is correct as the business case is the same: it should validate when it's supposed to. All the changes will be in the step definitions. This means that there is no reason to have another discussion with your stakeholders about whether your scenarios are still testing the right thing.
You can write the scenario, somewhat like this:
Given the user launches the application
When user login with valid credentials
And navigates to required page
Then he should see the page datails
Inside the Then step you manage all the logic.
Then(/^he should see the page details$/) do
if condition
...
else
...
end
end
Gherkin is not a programming language to use if or else conditions. It is a part of BDD framework, that is implemented, to make the stakeholders and other non technical resources understand what the test process is about. Hence, it is always recommended, you keep the gherkin as simple and as generic as possible.
Strictly speaking you should create an alternative statement along the lines of:
Given user launches the application
When user login with valid credentials
and navigate to required page
When String str is NOT "XYZ"
If you have a simple form, you enter your name, Gender and save it. When you select the Gender drop-down it will list [Male | Female].
So when writing test scenarios for the above, the typical way is to Write it in steps.
Precondition : User Loged in and Form Opened
Steps | Expected Result
------------------------------------------------------------------------
1 : User Enters the name | Entered name should be there
2 : User Clicks on Gender Drop-down | Male and Female should be listed
3 : Users Selects a Gender | Selected Gender should be there
4 : Clicks on Save | Information get saved.
Following is one way to represent this is Cucumber.
Given User Loged in and Form Opened
When User Enters the name
Then Entered name should be there
When User Clicks on Gender Drop-down
Then Male and Female should be listed
When Users Selects a Gender
Then Selected Gender should be there
When Clicks on Save
Then Information get saved.
Now How can we represent this in Cucumber? As I read you are not suppose to have multiple actions within the same scenario. If you add multiple testcases for each step above, the Testcases will grow exponentially. What is the best way to handle this?
My approach would be to think about documenting in Gherkin (using principles of BDD) - the application behavior and not test cases.
In fact, this article provides some good context around misconceptions of BDD.
With that said, even though you are trying to validate the above criteria in a single scenario, I would recommend at least splitting into 2, to keep your acceptance tests succinct, readable and maintainable.
Here's my attempt, at reformulating:
Scenario: Gender Dropdown values
Given a user is logged in
When the user clicks the Gender dropdown
Then Male and Female options are displayed
#EndtoEnd
Scenario Outline: Saving User information
Given a user is logged in
When the user enters a <Name> and selects a <Gender>
And Clicks on Save
Then the information gets saved
Examples:
|Name|Gender|
|Keith|Male|
|Jenn|Female|
||Female| # Negative
|Rob|| # Negative
Additionally, you can also think about throwing in some negative test scenarios as well.
If you need to test on cucumber with multiple data, you can go ahead and use the scenario outline feature, where you load the data in the examples after the scenarios.
Scenario Outline: User enters details and stores
Given User Loged in and Form Opened
When User Enters the <Name>
And Users Enters the <Gender>
And Clicks on Save
Then Information get saved.
Then I Go back (In case view info)
Then I assert for <Name>
Then I assert for <Gender>
Examples:
|Name| |Gender|
|x| |Male|
|y| |female|
Cucumber is not about testing how you do things, its about specifying why you do things. This scenario is all about how the user interacts with the form, its all about clicking on this and entering that, none of this has any place in scenarios.
Your scenario and question doesn't even tell us what you are trying to do, so I'll just have to make something up. Lets say you are trying to add a friend
Feature: Adding a friend
Scenario: Add Alison
Given I am logged in
When I add Alison to my friends
Then I should see Alison is my friend
and thats pretty much that. Note how none of the details about how you add a friend are captured in the scenario, thats not what Cucumber is for.
Now on the technical side lets explore how we get this scenario to actually add a friend. First of all the step definition
When 'I add Alison to my friends' do
add_a_friend name: 'Alison' # perhaps add a gender param here
end
Notice how even the step definition doesn't know how to fill in the form.
Finally a helper method to actually do the work (done in Ruby cos its clearer)
module FriendStepHelper
def add_a_friend(name:)
# here is where we fill in the form and choose the gender
end
end
World FriendStepHelper # makes add_a_friend visible to step def
So technically this is how you represent your problem in Cucumber you write WHY you doing things in using your scenarios and you push down HOW you do things to helper methods used by your step definitions
I am using cucumber in combination with selenium for testing the java web application. The following is the Scenario that we have
get generate PIN page
enter user name
enter password
click on submit button
Now it generates a PIN in the database depending on so many calculations. now i need that particular PIN, to give it as an input to a different scenario. how can i achieve this? Thanks in advance.
I would assume that you can access the PIN within the database after the above scenario. That being the case, I would add one more step to the scenario that acquires - and confirms - that the PIN was indeed generated. At that point, you can store the PIN in a local variable and then use it within the next scenario.
So your first scenario would look like this:
Get generate PIN page
Enter user name
Enter password
Click on submit button
Confirm PIN number in database
The last step would not be done within Selenium, but via an API call or some other means to acquire the PIN from the database. It would confirm the PIN (e.g.; regex=/^\d{4}$/) and then store it in a local variable, say something like #customer_pin (assuming you're using Ruby).
Your next scenario would start off something like this:
Get generate login page
Enter customer ID
Enter customer PIN
etc
When you hit the "Enter customer PIN" step, you pull it from the locally stored variable (#customer_pin).
My advice is that when executing this second scenario, you confirm that you have a legitimate PIN within your locally stored variable, in case someone should run this scenario out of sequence. You could do this by using a global variable and running a "Before" hook in your features/support/env.rb file like this:
Before do
$dunit ||= false
return if $dunit
$customer_pin = nil
$dunit = true
end
In this case, I use $customer_pin instead of #customer_pin in order to make the variable globally accessible. Then after running your first scenario, $customer_pin would be assigned to a legitimate value so that it can be used in any subsequent scenarios. Subsequent scenarios would use the regex expression to confirm it has a legitimate value, and raise/throw an exception if not.
I would divide your problem into two.
One that verifies the pin generation as this may be important for your stakeholders.
One that implement a backdoor to support other cases where a valid PIN is needed. Maybe an API that is able to generate or retrieve a valid pin number. Maybe create and store the PIN in the database without touching the system from the outside. I would use this way to retrieve a PIN whenever I need a valid PIN for other scenarios.
The technical solution on how to get a valid PIN isn't too important. What is important is to decouple the execution order of the scenarios. The execution order of the scenarios is undefined. Each scenario must be able to be executed in isolation and in random order.
Coupling scenarios is a well known anti pattern described here and here.
To Solve this kind of situation you have to use Cucumber Background feature, This is run before each step. and will generate a PIN based on given inputs and then generated PIN will be available across the scenarios.
Find feature file definition based on your requirements.
Background:
Given I Get generate PIN page
Then I Enter user name
And Enter password
And I Click on submit button
And I Confirm PIN number in database
#TC01_GetUserInformationByPinTest #NoBrowser
Scenario: Get User information by generated PIN from background.
Given I Get User Information by using generated PIN
And I verified that given username is same as response Data
I believe this will help you to solve your issue.
Is it possible to reuse a feature as the "Given" for another feature?
Or am I trying to do something I shouldn't be trying to do
basically my features look like:
Scenario: Creating a basic account with valid details (happy path)
Given I am on the "signup" page
And I enter all the right details #this is shortened of about 20 steps for your reading ease
When I press the button labelled "Sign up"
Then I should see the text "Thanks for signing up"
And I should have an email from "confirmation#mysite.com" titled "Confirm your account Michael"
And the database should contain a record for the user marked as unconfirmed
Scenario: Confirming account via email
Given I have created a basic account
When I open the confirmation email and visit the url to confirm the account
Then I should be logged in
And the database should contain a record for the user makred as confirmed
I clear my DB after every feature as they should all be able to be run individually...
Am I going about this the wrong way?
Thanks
The Problem
What you're actually attempting is to reuse a scenario. This is no longer supported in Cucumber.
Aside from other problems with this approach, your tests will be slower and interdependent, since you will be:
driving account creation through a browser, and
making all your tests dependent on the account-creation test passing.
Don't do that.
The Cucumber Way
Generally, you should write your tests to work independently, although you can certainly reuse step definitions. So, in the general case, you might want to add shared steps like:
Given that user account "Test User" does not exist
Given that user account "Test User" exists
which can then be included in your scenarios as needed. The nice thing about this approach is that the steps can create or delete users programmatically.
Alternatively, if most of your tests will be on existing accounts, set up the default data set with the right user fixtures already in place. For the limited subset where you will be testing account creation, just add a scenario background that drives user deletion.
In case you are using Javascript, I've created a package named reuse-cucumber-scenarios for calling a scenario by doing:
Given the scenario "#scenario_tag"
.
Given the scenario "#scenario_tag" with parameters
"""
{
"1": ["step1_param1", "step1_param2"],
"2": ["step2_param1", "step2_param2", "step2_param3"],
"3": ["step3_param1", "step3_param2", "step3_param3"],
}
"""
or creating gherkin variables...
Given the variable "$variable_name" is equal to
"""
#JSON object
"""
or creating scenario functions and calling them by doing...
Given the scenario "#$scenario_function_tag" where variable "$variable_name" is "value_to_replace"
and more...
Currently, you can use the following approach:
Background:
Given Some common setup
And Some more setup
Scenario: one
When setup1
Then something1
Scenario: two
When setup2
Then something2