I have the following Gherkins:
Given i go to the URL
And i enter the <NRIC or FIN> as NRIC / FIN
And i select the option to proceed Next
And i select the first available available Handset Color
And i select the option to proceed Next
And i enter <Full Name> as Name
When i select the option to proceed Next
The "I select the option to proceed Next" appears three times. How should this be written as in the Step Definitions Java class file?
As well as the Declarative/Imperative question have a think about what requirement you're describing. I find it's helpful to include the Scenario: in the examples for this reason. It's very unusual to have that much detail in a Given step
Are you testing the creation of an order (bit of a guess)? If so then your enter/select steps should be the Whens in the scenario, so something like:
Scenario: Create a new order
Given I have gone to the URL
When I enter the NRIC/FIN: <NRIC/FIN>
And I choose the first available Handset Colour
And I enter <Full Name> as Name
Then my new order should be confirmed (or whatever)
However, if you're creating the order simply to set up the scenario to test something else then you can cheat and just state that the order should exist:
Scenario: Check the status of an order
Given that I have created an order:
| NRIC/FIN | Colour | Full Name |
| xxxxx | Red | John Doe |
When I check the status of my order
Then I should see a new order...
It's up to the automation whether it clicks through the screens to create that order or just inserts it into the database, all that matters is that by the time you get to the Whens the order should exist.
In an ideal BDD world the Gherkin would be written before the implementation, but it often doesn't work that way. I still find it useful to try and pretend I'm writing the Features in that ideal world. Asking "How would I have written this before we started development?" can help to separate the actual requirements (I can enter an order) from implementation details (I click Next after entering each item of data).
When writing cucumber scenarios you can adopt either a imperative or declarative style. I would prefer to write the same thing as below.
Given i go to the URL
And i enter NRIC / FIN
And i select the first available Handset Color
And i enter <Full Name> as Name
Then I should see that
So it depends on who is going to read your scenarios. A link worth reading is imperative - declarative
Related
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
This is my first time doing cucumber, so maybe what im asking isn't wrong but it just seems like there is a better way:
So right now im going through a survey-like website as my first automation task with cucumber. It works just fine, but like most surveys theirs a lot of "Fill then out, then click Next"
so in my Feature file I have a lot of:
Then I will click 'Next'
Which matches with the step (Since the button all have the same text):
Then(/^I will click 'Next'$/) do
click_button('Next')
end
So this one step definition defines like 8-9 lines in my feature file...which I guess is ok, but my feature file just looks...ugly? Im not used to the Gherkin language AT ALL as this is my first time, but it's basically turned into a lot of:
THEN SELECT THAT THING FROM DROPDOWN
THEN CLICK THIS RADIO BUTTON
THEN SELECT THIS BUTTON
THEN CLICK NEXT
Like over and over....I mean it's human readable, but it just looks messy? is this right?
Also im not really sure when I should use "explicits" in my feature file? Like should I explicity say Im going to select 'X' (or "X", not sure if it matters) from a dropdown? or Click the 'Next' button or select the 'yes' radio button for example?
You are writing what are called imperative steps and it is indeed the wrong way to go about cucumber/gherkin.
Your steps should be saying "WHAT" you are doing and not "HOW" you are doing.
Not knowing the details of your form, let's make up a flow.
Page 1. Name
Page 2. Demographics
Page 3. Favorite football team
Page 4. Favorite basketball team
Page 5. Results page showing how popular their teams with other survey takers
Given I enter the "Are you a Bandwagon Fan Survey"
When I enter my name
And I enter my demographics
And I choose a favorite football team
And I choose a favorite basketball team
Then I should be directed to the result page
And I should see my teams ranked on a graph
The details for entering your name and clicking next should be hidden inside that stepdef. A person trying to test your app doesn't care what the name is, or what the field ID is or anything like that. They just want to know the work flow.
If you are doing scenarios to get the name page to error you simply modify your gherkin to say something like.
When I enter a name too long
Then I see a name too long error message
When I do not enter a name
Then I see a name missing error message
Again, you leave the details of too long or what the error message is to the step def (or below) unless it is critically important to the test scenario. I usually set up factory girls to handle my data and just use the text of the scenario to pull the current data. so I'll have an error message factory and within that a "name_missing" and a "name_too_long" sub-factory that provide the correct values. If I need to change or look something up, everything is in the same place...but above all it's not cluttering my gherkin.
Yes I think you want to send parameters to step definition
Then I will click 'Next'
Step definition will be
Then(/^I will click "([^"]*))*"$/) do |text|
click_button(text)
end
also above will work for
Then I will click 'OK'
I have created the below diagram and I wanted to know if the diagram that I have done is correct.
The below diagram is based on an android application. When the application loads the user is given 3 button to select add, update and help. On click on add button the user is given an option to add a new user or add a new item. When he select either of the options he enters the required data once the data is entered the system check if all the values are entered correctly and then finally saved. The same process is applied for update.
Your diagram misses an entry point. Though it's rather obvious that the top action is the start, only the entry point is the one indicating the beginning.
You can omit most of the diamonds and directly transfer via a guard from actions. So your conditions should be guards and written as [Yes] or [No]. The top most action (and quite some others) is(/are) indeed what should be written inside (or aside) the diamond below.
An excerpt for an update could look like this:
Finally Values added does not look like an action but rather as state. It should be omitted. Alternatively use differently named end flows.
So far for the formal points. But as #eyp said: it's a good one and one can understand what you tried to express. The above is just for the picky teachers.
It's a good one but it lacks some detail in the diamonds. You should write besides the diamon the question before choosing the next setp to do.
For example in the diamond after Check update value you may write is valid? or another question that clarifies more the business logic.
I understand the difference between imperative and declarative cucumber steps, but I have not seen any real world examples of this. I always feel like my feature files are becoming too verbose.
It seems like there would need to be a cucumber feature for each step in the life cycle:
foobars/list_foobars.feature
foobars/create_foobar.feature
foobars/view_foobar.feature
foobars/edit_foobar.feature
foobars/delete_foobar.feature
In the create feature alone, it seems like you would want to list out the fields that can be entered, which ones are required, what happens when you enter invalid data, etc. I don't know of a declarative way to do this. Of course in subsequent features, you would just say Given a foobar exists rather than going through all the steps to create one.
How detailed do you go when describing your application's behavior? Can you provide some examples of feature files that you feel are acceptably complete?
I like to keep cucumber tests human readable, so assuming we have a story for editing a foobar with invalid data, I'd want a scenario like:
# foobars/edit_foobar.feature
Feature: As a user, I want to edit a Foobar, so I can Baz
Scenario: Validation Errors
Given I am logged in as a user
And a foobar exists
And I edit the foobar with invalid data
Then I should see validation errors
I think that captures what we want out of the story, without having to deal with all the details of which fields to edit, what buttons to submit, etc. It doesn't test all the possible cases, but those should really be tested via unit tests (model tests that the validations are set, and controller tests that the flash messages are set or request tests that the errors are being served).
The other scenarios are similar:
Scenario: Successful Edit
Given I am logged in as a user
And a foobar exists
And I edit the foobar with valid data
Then I should see the valid data
Some people will want to specify the valid data as part of the test itself, but I personally prefer to delegate these to the step definitions in order to keep the scenarios clean. You just need one example to make sure the golden case works, because again this isn't the appropriate place to test that all the form fields work (and it will become a maintenance headache if you do specify every single field).
I am thinking maybe not test this at all using Cucumber, instead just make a comment in the Feature section.
Alternatively maybe one can do something like this:
# categories.feature
Scenario: Manage categories
Given I want to manage categories
When I <crud_type> a category
Then I should be taken to the listing page
Examples:
| crud_type |
| create |
| edit |
| delete |
Scenario: View category
Given I want to view a particular category
When I click on a category in the category list
Then I should see that category's view page
This requires a detailed explanation.
Imagine that I have an Excel spreadsheet with test cases in one worksheet
and I may have expected (validation) messages in another (in addition to expected messages in the first worksheet).
There is also some linking between the values of fields in one to the second worksheets.
See: Welcome, <First Name> <Last Name> as an example.
You can see in the "Expected Results" field in "Test cases" worksheet the value of the field is:
"The user is taken to My Account page and following welcome message is displayed:
"&Messages!$B$1244&", where First name is Dave and Last Name is Brown."
so "&Messages!$B$1244&", denotes field B1244 in worksheet "Messages"
Now the question.
If I am given all test cases like the example below for an ecommerce web site, how can I use Coded UI Testing based on this input? Can I automate Excel, use the steps in test case worksheet and combine that with Coded UI recording of data input and verification.
I believe I would need to do manual coding, partially using recorded input steps and verifications from Coded UI recorder and possibly using manual programming for verification.
I would like to hear if others have done something similar.
I would like to incorporate this into Specflow BDD, by writing feature/user story and these test cases will be scenarios.
Any success, thoughts on using Excel test automation as data driven testing.
Thanks
Rad
Test cases worksheet named "Test cases":
=====================
Test Case Name Test Case Objective
frontstore.01-3 Register a shopper from order
confirmation page with valid inputs
# Step Data Expected Results
------------------------------------------------------------------------------------------------
1 Launch the test storefront http://testserver.com/index Welcome page is loaded.
2 Click Sign In link Sign In page is loaded.
3 Click Register under New Customer Register page is loaded.
4 Enter valid inputs and click Submit "Logon ID = TestUser
Firstname = John
Lastname = Clark
... (other fields) Registration Successful.
The user is taken to My Account page
and following welcome message is displayed:
Welcome, <First Name> <Last Name>, where First name is
David and Last Name is Brown."
Validation Messages worksheet named "Messages":
=====================
#Text used in MyAccountPages
---------------------------------------------------------------------------
MA_WELCOME Welcome, <First Name> <Last Name>
After reading a bit about Coded UI testing:
It can certainly be done, but data/sentences like:
“Launch the test storefront”
“Click Sign In link”
“Registration Successful.
The user is taken to My Account page
and following welcome message is displayed:
Welcome, , where First name is
David and Last Name is Brown."
contain both actions and data so I need to drill down into parts of the sentence to
translate it to actions and binding to parameters.
If I understand well data binding can only be used to bind column values to some parameters.
So I need some way to automatically recognize the meaning of these sentences and use some binding
from parts of it.
So if I have a sentence:
“Launch the test storefront” that would be translated to:
CurrentBrowser.Navigate(Helper.TranslateTargetUrlFrom(“test storefront”))
where “test storefront” might resolve to http://testserver.com/index storefront home
page and I can ignore Data column for URL
or I can capture Launch keyword to mean CurrentBrowser.Navigate(ColumnValue(Data)) and ignore “test storefront” part of the sentence.
“Click Sign In link” could be translated to CurrentBrowser.FindLink(“Sign In”).Click(),
so it this case I will need to know that Sign In is
the text of the link, again I need to extract “Sign In” to mean the text of a link.
I see this as pretty manual style of CodedUI where I could do small recording for some actions and rely on manual extractions of terms from
given sentences.
I would like to know how can I semantically write better test cases to allow automation. I would probably need some kind of free form
test case parser that would recognize the semantic meaning of some words like: click, navigate, launch, enter, click under etc and translate this into
code by re-using existing helper methods and recorded actions and do some manual binding, but not with the whole data value in the column, but
an extracted value.
Any idea of this kind of automation?
I think yould could do this by data binding the input parameters and just reading Excel as a datasource, you are going to need to use CodedUI for that not MTM + Fast Forward