2

I'm currently part of a team that is trying to reinforce BDD in our tests and automation. Our tests up to this point were procedural and we want to move towards behavioural steps. An example of our procedural test is printed below

Given I am a registered customer
And A browser has been opened
When I login
And I open the settings dropdown
And I go to my preferences page
And I set email notifications to true
Then Email notifications in the db should be on

The above is purely procedural, and if I’m not mistaken, what we should be moving away from. In my opinion, a more behavioural test would be something like

Given I am a registered customer
When I enable email notifications
Then Email notifications in the db should be on

Much easier to read and cuts out the procedural steps that we don’t care about. The problems lay in step definitions though. In the first example, the step definitions are simple, one action needed and most importantly, the step before each step sets up the step in question (e.g. setting the notifications to true is no problem because the previous step brought us to the My Preferences page). But in the second example, if we wanted to automate it, where do we log in? Which step takes on that task? First or second? Which step takes on the task of actually navigating to the My Preferences page?

I also can see issues with reusing steps in unrelated steps. If we add behaviours to steps that aren't clarified in the step title, it will cause issues

Anyone have any advice on the line you draw between procedural steps and behavioural with automation in mind?

Thank you

1

Gherkin should also be devoid of technical details. The fact the notification setting is saved to the database does not belong in a scenario. The fact notifications are turned "on" does belong. I would just change the wording in your Then step to:

Then email notifications should be on

Also notice that "email" is all lower case, since it is not a proper noun, although depending on your writing style guide it might be.

Beyond that, logging in is a valid step. It's communicates that this action requires being authenticated, which is a pretty important detail. You also cannot assume that every scenario that requires a registered user will also log the user in. Imagine a scenario where an unauthenticated registered user needs to verify their access to the site, for instance.

The step When I enable email notifications should navigate to the settings page.

0

I have not much worked on Cucumber but.. as per my understanding Gerkins file used to create Step defination template. Main usage of Gerkins is to make code readable. and all logic are code in Code Templet generate after running Gerkings file.

Based on all testcases, gerkins files are written such a way that minimum methods generated using Gerkins file.

0

First of all, you are trying to define your cucumber framework. There is so much different approach about it. Some part of developers says "assertions should be on another class" and some of them says "assertion should be under steps". You should choose your approach according to your behaviour. And also the code you shared has steps and assertion. You should also decide to how to use steps, but the most common usage of steps structure is like code you shared at first block. I will try to explain it.

Explanation of your code : 
Given I am a registered customer (User state)
And A browser has been opened (This operation can be in your hooks)
When I login (Operation)
And I open the settings dropdown (Operation)
And I go to my preferences page (Operation)
And I set email notifications to true (Operation)
Then Email notifications in the db should be on (Assertion)

You can implement(Merge) below methods to each other as :

And I open the settings dropdown (Operation)
And I go to my preferences page (Operation)

And I go to my preferences page from dropdown menu (Operation)

This method should clicks 'preferences' under drop down first, then you should assert that you are on the preferences page however if you are using this approach you should use it on every operation

Or you can write a method like below :

And I go to my <string> page from dropdown menu (Operation)

So it can click any item under the dropdown according to text you provide as string and you can use it with every dropdown operations.

For assertions :

You can assert every operation under step definitions file or you can assert them with another assertion object which make it more readable of your assertion under feature files.

Given I am a registered customer (State)
And A browser has been opened (Assertion)
When I login (Operation)
Then I user should be logged in (Assertion)
And I open the settings dropdown (Operation)
Then Dropdown should be visible (Assertion)
And I go to my preferences page (Operation)
Then I should be on preferences page (Assertion)
And I set email notifications to true (Operation)
Then Email notifications in the db should be on (Assertion)

Or you can move that assertions under your step definitions which is I am not prefer because of seeing assertions easily under feature files .

Given I am a registered customer (State)
When I login (Operation and Assertion)
And I open the settings dropdown (Operation and Assertion)
And I go to my preferences page (Operation and Assertion)
And I set email notifications to true (Operation and Assertion)
  • 1
    Thanks for your input Selcuk. After working on it over the last month and with your insight, it's becoming a lot clearer. – JordiLaForge Feb 27 at 9:48
  • A single test case should consist of no more then 3 to 4 steps. OP was on the right track, this is just pointing the opposite way, complex interactions do not belong in gherkin steps. – Moro Nov 5 at 8:56
  • It is just an opinion about test optimisation, I don't have to follow any basic rule set of any framework, language or tool because i have my own app or system which i should decide to create what kind of tests i will create. – Selçuk Ayhan Nov 6 at 9:20
  • You are free to work however you like, but it is stack exchange and your opinion might influence others to use the tool the wrong way. Read some about cucumber anti patterns: thinkcode.se/blog/2016/06/22/cucumber-antipatterns – Moro Nov 6 at 9:57
  • as you can see in the question title, this is about complex step definitions and behaviours. and also the questioner have solution now. – Selçuk Ayhan Nov 6 at 11:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.