[Cucumber] How to you deal with long, e2e test scenarios in Cucumber?

[Marek Siemieniuk-Morawski]

Hey,
I'm facing with the problem of designing acceptance tests for the
application being some kind of long form web app (let's say it's a survey
app). It's not technically hard to write the scenario that pass through the
flow from the very first page to the last one. The challenge is how to do
it smart, according to best practices. As far as I understand how good
Cucumber's scenario should look, the scenario must:
- be able to run independently of other scenarios,
- contain *only one *When keyword,
- contain *at most* 5 steps,
- steps should be reusable as much as possible.

So, after many hours of reading, trying, and thinking, I created a scenario
as below.

Scenario: Successfully pass through the flow of the application
Given I got access to the very first page of the Application
When I choose the 2nd option on First page
Then I should be navigated to /second-page page
When I provide my personal data in Second page:
| input | value |
| some_data | some_value |
| some_data2 | some_value2 |
| some_data_consent | true |
Then I should be navigated to /third-page page
When I provide my personal data in Third page:
| input | value |
| some_data | some_value |
| some_data2 | some_value2 |
Then I should be navigated to /other-page page
When I provide my personal data in Other page:
...

Then I should be navigated to /last-page page


It works, but I accomplished only one of the "best practices" - steps are
very reusable. That's why I'm writing the post, to ask you what do you
think about the scenario, the assumption that I follow, and how would you
do in my place? I believe there are many places for improvements.

[Andrew Premdas]

Here are some techniques that are key to writing the sort of scenarios you
are talking about. They are all focused on differentiating between WHAT you
are doing, WHY its important and HOW you do things.

1. Push the HOW down. HOW has no place at all in scenarios! So anything to
do with pages, options, filling in things should not be in your scenario
2. Discover WHAT you are trying to do and give it a name. Use the rest of
the feature file to document WHY this thing is important and to set the
context for your scenarios
3. Break up the functionality of your application into appropriately sized
chunks. Each chunk should have ...
3.1 A name that is unique and meaningful in your business context
3.2 Can be developed in short period of time (max 2 weeks, ideally less
than this)
3.3 Be immediately important to your business context
3.4 Be useful for future work


We can easily apply this to your current scenario

Scenario: Successfully pass through the flow of the application
Given I start using the application
When I use the application
Then the application should work

However this fails to meet any of the criteria in part 3. There is no
meaningful name, it can't be developed in a short period of time. Its not
immediately important to your business context (its a long term goal for
all of your application to work). Its not at all useful for future work.

Unfortunately your scenario is a terrible started point for this sort of
discussion!!

The difficulty with writing really good Cucumber scenarios is that each one
should be

1. Specific to your particular business domain
2. Dependent on existing behaviour that is specific to your particular
business domain
3. Addressing an immediate business need
4. Be based upon a deep understanding of your particular business context

So discussing them with strangers can be quite challenging. This is why I
mostly use the login scenario and basic e-commerce scenarios to illustrate
HOW to write simple, short scenarios because there is a common context
which everyone can understand, and this allows you to focus on technique.

So what are the next steps for you? I'd suggest

1. Go back and look for a scenario that is specific to your business.
2. Remove the HOW from the scenario - no navigation, pages, clicks
3. Focus on the preamble in the feature, the features name, and its place
in your hierarchy of features.

So you a pushing the details DOWN and are looking up to find higher level
abstractions that have great names and reasonable chunk size.

Hope this is of some use

All best

Andrew

Post by Marek Siemieniuk-Morawski
Hey,
I'm facing with the problem of designing acceptance tests for the
application being some kind of long form web app (let's say it's a survey
app). It's not technically hard to write the scenario that pass through the
flow from the very first page to the last one. The challenge is how to do
it smart, according to best practices. As far as I understand how good
- be able to run independently of other scenarios,
- contain *only one *When keyword,
- contain *at most* 5 steps,
- steps should be reusable as much as possible.
So, after many hours of reading, trying, and thinking, I created a
scenario as below.
Scenario: Successfully pass through the flow of the application
Given I got access to the very first page of the Application
When I choose the 2nd option on First page
Then I should be navigated to /second-page page
| input | value |
| some_data | some_value |
| some_data2 | some_value2 |
| some_data_consent | true |
Then I should be navigated to /third-page page
| input | value |
| some_data | some_value |
| some_data2 | some_value2 |
Then I should be navigated to /other-page page
...
Then I should be navigated to /last-page page
It works, but I accomplished only one of the "best practices" - steps are
very reusable. That's why I'm writing the post, to ask you what do you
think about the scenario, the assumption that I follow, and how would you
do in my place? I believe there are many places for improvements.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

--
------------------------
Andrew Premdas
blog.andrew.premdas.org