References describing why and how to avoid scenario dependencies

[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 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

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

[Quentin Crain]

Hi!

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

Quentin

[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

On Thursday, September 7, 2017 at 9:41:00 AM UTC-4, Aslak Hellesøy wrote:

[aslak hellesoy]

It's mentioned in chapter 3 and 6

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[George Dinwiddie]

Quentin,

Rather than thinking of Cucumber scenarios as testing scripts, think of
them as descriptions of functionality.

On 9/7/17 9:13 AM, Quentin Crain wrote:
> 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

As Aslak says, these scenarios don't tell the whole story. They require
implicit knowledge contained in other scenarios.

> 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

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

> 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

> 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?

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

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