Behavioural Gherkin Steps requiring complex Step Definitions when Automating

Question

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

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

Answer 2

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.

Answer 3

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)