Discussion:
[Cucumber] References describing why and how to avoid scenario dependencies
(too old to reply)
Quentin Crain
2017-09-07 13:13:58 UTC
Permalink
Raw Message
Hi!


I have searched the archives but have not found any answers which provided
links to documents explaining why ordered dependencies between scenarios
(vs features) is considered bad; are there any?


Lets just make up a simple example, and perhaps it can be a starting point.
Imagine this feature file:


Feature: Depositing Monies


Scenario: Create Account

Given a bank

When I create an account for Bob

Then the account is created

And the account's balance is $0.00


Scenario: Depositing $5.00 increases the balance by $5.00

Given Bob's account

When I deposit $5.00

Then the account's balance is $5.00



Scenario: Depositing $10.00 increases the balance by $10.00

Given Bob's account

When I deposit $10.00

Then the account's balance is $15.00



Without scenario dependencies, this would be:



Scenario: Creating an account for Bob and starting with a balance of $0.00,
depositing $5.00 results in a balance of $5.00

Given a bank in which I create an account for Bob with an initial balance
of $0.00

When I deposit $5.00

Then the account’s balance is $5.00



Scenario: Creating an account for Bob and starting with a balance of $5.00,
depositing $10.00 results in a balance of $15.00

Given a bank in which I create an account for Bob with an initial balance
of $5.00

When I deposit $10.00

Then the account’s balance is $15.00


(If there is a 3rd version that is the canonical and preferred version of
this, that would be awesome to know! grin!)


The first feature file is much more representative of how the world works,
meaning it is a truer test of real-world conditions: Deposits come in over
time. Also, the first is much more likely due to test accretion: The very
first test I might write is "Can I create an account and its initial
balance should be $0.00". Later I might find it important to test
depositing. The second version requires me to do more testing that I might
want to do at any moment in time.


In short, I have never read a good justification for the disapproval of
scenario dependencies.


Reference would be much appreciated! Thanks!!


Quentin
--
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 email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Aslak Hellesøy
2017-09-07 13:41:00 UTC
Permalink
Raw Message
Interdependent scenarios are hard to fix when they break.
Because they are interdependent, running a single one will give a different
result, so you have to run them all. Your feedback loop will be very slow
and it will take a long time to fix scenarios.

Also, you can only fix one at a time - if one fails, all the subsequent
ones are running in an unknown context.

They also become poor documentation. You can't read a single scenario and
understand what behaviour it's illustrating - you have to read them all.
That's too much to keep in most people's heads.

There's more in the Cucumber book.
Post by Quentin Crain
Hi!
I have searched the archives but have not found any answers which provided
links to documents explaining why ordered dependencies between scenarios
(vs features) is considered bad; are there any?
Lets just make up a simple example, and perhaps it can be a starting
Feature: Depositing Monies
Scenario: Create Account
Given a bank
When I create an account for Bob
Then the account is created
And the account's balance is $0.00
Scenario: Depositing $5.00 increases the balance by $5.00
Given Bob's account
When I deposit $5.00
Then the account's balance is $5.00
Scenario: Depositing $10.00 increases the balance by $10.00
Given Bob's account
When I deposit $10.00
Then the account's balance is $15.00
Scenario: Creating an account for Bob and starting with a balance of
$0.00, depositing $5.00 results in a balance of $5.00
Given a bank in which I create an account for Bob with an initial balance
of $0.00
When I deposit $5.00
Then the account’s balance is $5.00
Scenario: Creating an account for Bob and starting with a balance of
$5.00, depositing $10.00 results in a balance of $15.00
Given a bank in which I create an account for Bob with an initial balance
of $5.00
When I deposit $10.00
Then the account’s balance is $15.00
(If there is a 3rd version that is the canonical and preferred version of
this, that would be awesome to know! grin!)
The first feature file is much more representative of how the world works,
meaning it is a truer test of real-world conditions: Deposits come in over
time. Also, the first is much more likely due to test accretion: The very
first test I might write is "Can I create an account and its initial
balance should be $0.00". Later I might find it important to test
depositing. The second version requires me to do more testing that I might
want to do at any moment in time.
In short, I have never read a good justification for the disapproval of
scenario dependencies.
Reference would be much appreciated! Thanks!!
Quentin
--
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 email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Quentin Crain
2017-09-07 13:50:48 UTC
Permalink
Raw Message
Hi!

Great, thx! I get the book for the fleshed out explanation of these
arguments.

Quentin
Post by Aslak Hellesøy
Interdependent scenarios are hard to fix when they break.
Because they are interdependent, running a single one will give a
different result, so you have to run them all. Your feedback loop will be
very slow and it will take a long time to fix scenarios.
Also, you can only fix one at a time - if one fails, all the subsequent
ones are running in an unknown context.
They also become poor documentation. You can't read a single scenario and
understand what behaviour it's illustrating - you have to read them all.
That's too much to keep in most people's heads.
There's more in the Cucumber book.
Post by Quentin Crain
Hi!
I have searched the archives but have not found any answers which
provided links to documents explaining why ordered dependencies between
scenarios (vs features) is considered bad; are there any?
Lets just make up a simple example, and perhaps it can be a starting
Feature: Depositing Monies
Scenario: Create Account
Given a bank
When I create an account for Bob
Then the account is created
And the account's balance is $0.00
Scenario: Depositing $5.00 increases the balance by $5.00
Given Bob's account
When I deposit $5.00
Then the account's balance is $5.00
Scenario: Depositing $10.00 increases the balance by $10.00
Given Bob's account
When I deposit $10.00
Then the account's balance is $15.00
Scenario: Creating an account for Bob and starting with a balance of
$0.00, depositing $5.00 results in a balance of $5.00
Given a bank in which I create an account for Bob with an initial balance
of $0.00
When I deposit $5.00
Then the account’s balance is $5.00
Scenario: Creating an account for Bob and starting with a balance of
$5.00, depositing $10.00 results in a balance of $15.00
Given a bank in which I create an account for Bob with an initial balance
of $5.00
When I deposit $10.00
Then the account’s balance is $15.00
(If there is a 3rd version that is the canonical and preferred version of
this, that would be awesome to know! grin!)
The first feature file is much more representative of how the world
works, meaning it is a truer test of real-world conditions: Deposits come
The very first test I might write is "Can I create an account and its
initial balance should be $0.00". Later I might find it important to test
depositing. The second version requires me to do more testing that I might
want to do at any moment in time.
In short, I have never read a good justification for the disapproval of
scenario dependencies.
Reference would be much appreciated! Thanks!!
Quentin
--
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 email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Quentin Crain
2017-09-07 14:07:41 UTC
Permalink
Raw Message
Hi!

I just reviewed the TOC and am wondering of the arguments are in chapter 6
"When Cucumbers Go Bad" or spread throughout the book?

Thanks!!

Quentin
Post by Aslak Hellesøy
Interdependent scenarios are hard to fix when they break.
Because they are interdependent, running a single one will give a
different result, so you have to run them all. Your feedback loop will be
very slow and it will take a long time to fix scenarios.
Also, you can only fix one at a time - if one fails, all the subsequent
ones are running in an unknown context.
They also become poor documentation. You can't read a single scenario and
understand what behaviour it's illustrating - you have to read them all.
That's too much to keep in most people's heads.
There's more in the Cucumber book.
Post by Quentin Crain
Hi!
I have searched the archives but have not found any answers which
provided links to documents explaining why ordered dependencies between
scenarios (vs features) is considered bad; are there any?
Lets just make up a simple example, and perhaps it can be a starting
Feature: Depositing Monies
Scenario: Create Account
Given a bank
When I create an account for Bob
Then the account is created
And the account's balance is $0.00
Scenario: Depositing $5.00 increases the balance by $5.00
Given Bob's account
When I deposit $5.00
Then the account's balance is $5.00
Scenario: Depositing $10.00 increases the balance by $10.00
Given Bob's account
When I deposit $10.00
Then the account's balance is $15.00
Scenario: Creating an account for Bob and starting with a balance of
$0.00, depositing $5.00 results in a balance of $5.00
Given a bank in which I create an account for Bob with an initial balance
of $0.00
When I deposit $5.00
Then the account’s balance is $5.00
Scenario: Creating an account for Bob and starting with a balance of
$5.00, depositing $10.00 results in a balance of $15.00
Given a bank in which I create an account for Bob with an initial balance
of $5.00
When I deposit $10.00
Then the account’s balance is $15.00
(If there is a 3rd version that is the canonical and preferred version of
this, that would be awesome to know! grin!)
The first feature file is much more representative of how the world
works, meaning it is a truer test of real-world conditions: Deposits come
The very first test I might write is "Can I create an account and its
initial balance should be $0.00". Later I might find it important to test
depositing. The second version requires me to do more testing that I might
want to do at any moment in time.
In short, I have never read a good justification for the disapproval of
scenario dependencies.
Reference would be much appreciated! Thanks!!
Quentin
--
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 email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
aslak hellesoy
2017-09-07 14:34:33 UTC
Permalink
Raw Message
It's mentioned in chapter 3 and 6
Post by Quentin Crain
Hi!
I just reviewed the TOC and am wondering of the arguments are in chapter 6
"When Cucumbers Go Bad" or spread throughout the book?
Thanks!!
Quentin
Post by Aslak Hellesøy
Interdependent scenarios are hard to fix when they break.
Because they are interdependent, running a single one will give a
different result, so you have to run them all. Your feedback loop will be
very slow and it will take a long time to fix scenarios.
Also, you can only fix one at a time - if one fails, all the subsequent
ones are running in an unknown context.
They also become poor documentation. You can't read a single scenario and
understand what behaviour it's illustrating - you have to read them all.
That's too much to keep in most people's heads.
There's more in the Cucumber book.
Post by Quentin Crain
Hi!
I have searched the archives but have not found any answers which
provided links to documents explaining why ordered dependencies between
scenarios (vs features) is considered bad; are there any?
Lets just make up a simple example, and perhaps it can be a starting
Feature: Depositing Monies
Scenario: Create Account
Given a bank
When I create an account for Bob
Then the account is created
And the account's balance is $0.00
Scenario: Depositing $5.00 increases the balance by $5.00
Given Bob's account
When I deposit $5.00
Then the account's balance is $5.00
Scenario: Depositing $10.00 increases the balance by $10.00
Given Bob's account
When I deposit $10.00
Then the account's balance is $15.00
Scenario: Creating an account for Bob and starting with a balance of
$0.00, depositing $5.00 results in a balance of $5.00
Given a bank in which I create an account for Bob with an initial
balance of $0.00
When I deposit $5.00
Then the account’s balance is $5.00
Scenario: Creating an account for Bob and starting with a balance of
$5.00, depositing $10.00 results in a balance of $15.00
Given a bank in which I create an account for Bob with an initial
balance of $5.00
When I deposit $10.00
Then the account’s balance is $15.00
(If there is a 3rd version that is the canonical and preferred version
of this, that would be awesome to know! grin!)
The first feature file is much more representative of how the world
works, meaning it is a truer test of real-world conditions: Deposits come
The very first test I might write is "Can I create an account and its
initial balance should be $0.00". Later I might find it important to test
depositing. The second version requires me to do more testing that I might
want to do at any moment in time.
In short, I have never read a good justification for the disapproval of
scenario dependencies.
Reference would be much appreciated! Thanks!!
Quentin
--
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.
--
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 email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
George Dinwiddie
2017-09-13 19:14:54 UTC
Permalink
Raw Message
Quentin,

Rather than thinking of Cucumber scenarios as testing scripts, think of
them as descriptions of functionality.
Post by Quentin Crain
Hi!
I have searched the archives but have not found any answers which
provided links to documents explaining why ordered dependencies between
scenarios (vs features) is considered bad; are there any?
Lets just make up a simple example, and perhaps it can be a starting
Feature: Depositing Monies
Scenario: Create Account
Given a bank
When I create an account for Bob
Then the account is created
And the account's balance is $0.00
Scenario: Depositing $5.00 increases the balance by $5.00
Given Bob's account
When I deposit $5.00
Then the account's balance is $5.00
Scenario: Depositing $10.00 increases the balance by $10.00
Given Bob's account
When I deposit $10.00
Then the account's balance is $15.00
As Aslak says, these scenarios don't tell the whole story. They require
implicit knowledge contained in other scenarios.
Post by Quentin Crain
Scenario: Creating an account for Bob and starting with a balance of
$0.00, depositing $5.00 results in a balance of $5.00
I'm not sure why you put the whole scenario in the title. What's wrong
with retaining the original title?
Scenario: Depositing $5.00 increases the balance by $5.00
or simpler:
Scenario: Depositing money to an account
Post by Quentin Crain
Given a bank in which I create an account for Bob with an initial
balance of $0.00
Why just an initial balance? Wouldn't the following work for you?
Given Bob has a balance of $0.00
Post by Quentin Crain
When I deposit $5.00
Then the account’s balance is $5.00
Scenario: Creating an account for Bob and starting with a balance of
$5.00, depositing $10.00 results in a balance of $15.00
I fear you'll be creating lots of scenarios if you check every possible
combination of balance and deposit. ;-) What's different about this
scenario from the previous?
Post by Quentin Crain
Given a bank in which I create an account for Bob with an initial
balance of $5.00
When I deposit $10.00
Then the account’s balance is $15.00
(If there is a 3rd version that is the canonical and preferred version
of this, that would be awesome to know! grin!)
The first feature file is much more representative of how the world
works, meaning it is a truer test of real-world conditions: Deposits
come in over time. Also, the first is much more likely due to test
accretion: The very first test I might write is "Can I create an account
and its initial balance should be $0.00". Later I might find it
important to test depositing. The second version requires me to do more
testing that I might want to do at any moment in time.
I note in your second set you dropped the fact that a new account should
be created with a balance of $0.00. (I also question that requirement.
Whenever I've opened an account, it required an initial deposit. Banks
don't seem to like inactive accounts.)

If you want to see what happens in real-world conditions, you can just
ship the code and see what happens. I find it better to set up the
conditions I care about, and make sure the system works the way I intend.
Post by Quentin Crain
In short, I have never read a good justification for the disapproval of
scenario dependencies.
Reference would be much appreciated! Thanks!!
Perhaps the references were in another conversation that this one
depends on. ;-)

- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
--
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 email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...