Multiple given,when and then in a feature file.

166 views
Skip to first unread message

Neethu V.M

unread,
Sep 1, 2015, 2:04:24 AM9/1/15
to Behaviour Driven Development
Is it possible to write a feature file like this?

Essentially the ability to do a check using then, before moving to the next when, again followed by then. (kind of IF-ELSE condition)

 

Scenario 1

Given……

When……….

Then……….

When………

Then……….

 

Scenario 2

Given……

When……….

Then……….

When………

Then……….

 

 

 

Tom Janssens

unread,
Sep 1, 2015, 5:22:56 AM9/1/15
to Behaviour Driven Development
Your path would be altered based on a given you defined before. 

Given an account has been locked
When this account places a new order
Then the order will be rejected

Given a valid account
When this account places a new order
Then his credit balance will update
And the order will be scheduled for verification



Op dinsdag 1 september 2015 08:04:24 UTC+2 schreef Neethu V.M:

Reinaldo Nolasco Sanches

unread,
Sep 1, 2015, 4:56:21 PM9/1/15
to behaviordriv...@googlegroups.com
The tool probably will execute it, but your scenario have a specific objective and you is trying to make checkpoints placing a group of scenarios in 1 scenario. A scenario have a pre-condition and actions to drive into a result, and you are trying to make a full path with some small scenarios to complete a "bigger scenario". Possibly you need:

Scenario 1
Given...
When...
And...
And...
And...
Then...


--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.



--

Gordon Mullan

unread,
Sep 2, 2015, 5:04:03 AM9/2/15
to Behaviour Driven Development
I don't like "And" on the "When".

In my opinion, it's OK (and quite common) to have multiple pre-conditions ("GIVEN this AND this AND this") and multiple assertions ("THEN this AND this AND this") but I always believe it's cleaner and less ambiguous to identify the single/final thing that is triggering the action.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message.


This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins Trading Company Limited, 733503, Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG or its parent company Travis Perkins plc (Registered in England No. 824821; Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG; VAT number 408556737) and any of its subsidiaries. Agreements binding Travis Perkins Trading Company Limited may not be concluded by means of e-mail communication.


E-mail transmissions are not secure and Travis Perkins Trading accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins Trading accepts no liability for infection and recommends that you scan this e-mail and any attachments.

Liz Keogh

unread,
Sep 2, 2015, 5:55:40 PM9/2/15
to behaviordriv...@googlegroups.com
Hi Gordon and Reinaldo,

The exception I've found for an "And" after "When" is when there are two people exercising the same behaviour, or something like time passing or another system responding; when the behaviour you're really interested in is the combination of two actions, rather than just one in a context.

So for instance:

    Given Bob has a trade for $92k of copper open for elaboration
    And Jane has the same trade open too
    When Jane saves it
    And Bob tries to save it
    Then he should be asked if he wants to merge Jane's changes.

There are ways of rephrasing this so that it only has one "when" and the first is a "given", but it doesn't match the way people speak or think about the actions.

So, if you're really trying to capture conversations (and provide an introduction to the tacit knowledge they generate), sometimes, it's OK to have two "whens". It happens even more if you're dealing with class-level BDD and examples, and there are threads involved...

Definitely not a standard case, though. I need to post that blog post (it's actually already written...)

All feedback welcome since I know there are tools that don't even support this!

What Reinaldo is talking about is a thing that we call a "Given Scenario"; where one scenario sets up the context for another scenario. It's a bit of an anti-pattern, but as with all patterns, they're appropriate to a context. If it's easier and more pragmatic to put two scenarios together, and you're just getting started, do the easy and pragmatic thing and be prepared to revisit it. This...

    Given Bob has filled in his details
    But forgotten to agree to the terms and conditions
    When he tries to submit the form
    Then he should be prompted to agree to the terms and conditions.
    When he agrees and submits again
    Then he should be told that he'll hear back within 24 hours.

...is fine, at least to get started. You'll probably run into a lot of other scenarios for which Bob agrees to the terms and conditions, at which point you can refactor those last two lines out. Think about the cost that you currently have for setting up the scenario, versus the cost you incur for loss of readability.

(I don't consider "catching bugs and knowing where the test broke" to be an important consideration, as the point is to prevent bugs from happening, not catch them. IMO TDD and BDD force good design and clear understanding way more than they catch bugs.)

Cheers,
Liz.

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message.


This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins Trading Company Limited, 733503, Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG or its parent company Travis Perkins plc (Registered in England No. 824821; Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG; VAT number 408556737) and any of its subsidiaries. Agreements binding Travis Perkins Trading Company Limited may not be concluded by means of e-mail communication.


E-mail transmissions are not secure and Travis Perkins Trading accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins Trading accepts no liability for infection and recommends that you scan this e-mail and any attachments.

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

Gordon Mullan

unread,
Sep 3, 2015, 5:33:07 AM9/3/15
to Behaviour Driven Development
Hi Liz

Hmmm - still not comfortable with either of those.

For the first one, I'd have said:

Given Bob has a trade for $92k of copper open for elaboration
And Jane has the same trade open too
And Jane saves her changes before Bob
When Bob tries to save it
Then he should be asked if he wants to merge Jane's changes

For the second one, I'd split into two, as you're checking two things - firstly, that forgetting to say you agree to T&Cs stops you submitting the form, and secondly, that when you do enter everything correctly. you get a confirmation message.  Two separate, through related, behaviours - one an error scenario, one a success scenario.

Given Bob has filled in his details
But forgotten to agree to the terms and conditions
When he tries to submit the form
Then he is prompted to agree to the terms and conditions
And the form is not submitted 

Given Bob has filled in his details
And indicated that he does agree to the terms and conditions
When he tries to submit the form
Then the submission is successful
And he is told that he'll hear back within 24 hours

Cheers
Gordon 
Liz.

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message.


This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins Trading Company Limited, 733503, Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG or its parent company Travis Perkins plc (Registered in England No. 824821; Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG; VAT number 408556737) and any of its subsidiaries. Agreements binding Travis Perkins Trading Company Limited may not be concluded by means of e-mail communication.


E-mail transmissions are not secure and Travis Perkins Trading accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins Trading accepts no liability for infection and recommends that you scan this e-mail and any attachments.

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

Dan North

unread,
Sep 5, 2015, 7:47:03 AM9/5/15
to behaviordriv...@googlegroups.com
Hi Gordon,

I’m afraid I’m with Liz on this one. I think of a scenario as a narrative that reads like this:

Title: How this scenario is different from other scenarios
- Given the world is in a specific state
- When an interesting event happens
- Then the application should behave in a certain way

For concurrency scenarios the interesting event is typically several-things-happening-at-once, usually in a way that represents a race condition or consistency mismatch. So in this scenario, the interesting event is Jane and Bob saving their changes in a particular sequence. I would expect to find other scenarios representing other sequences. (Could the save attempt fail for both users? Under what circumstances? Could multiple concurrent saves cause a deadlock or livelock?)

The context setup should be order-agnostic, as should the outcome checking. The only formal sequencing is that all the givens occur strictly before the interesting thing happens, and the interesting thing occurs strictly before the outcomes are checked.

I can see how both yours and Liz’s scenarios describe the same behaviour but I think Liz’s is more intention-revealing in terms of what makes the event interesting.

Cheers,
Dan


To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.


Dan North & Associates Ltd, registered in England and Wales, no. 6716833
Registered address: 38 Donnington Road, Worcester Park, KT4 8EN

Gordon Mullan

unread,
Sep 7, 2015, 10:33:20 AM9/7/15
to Behaviour Driven Development
Fair enough :-)
Hi Gordon,

Liz.

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsubs...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message.

This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins Trading Company Limited, 733503, Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG or its parent company Travis Perkins plc (Registered in England No. 824821; Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG; VAT number 408556737) and any of its subsidiaries. Agreements binding Travis Perkins Trading Company Limited may not be concluded by means of e-mail communication.

E-mail transmissions are not secure and Travis Perkins Trading accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins Trading accepts no liability for infection and recommends that you scan this e-mail and any attachments.

-- 
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsubs...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message.

This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins Trading Company Limited, 733503, Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG or its parent company Travis Perkins plc (Registered in England No. 824821; Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG; VAT number 408556737) and any of its subsidiaries. Agreements binding Travis Perkins Trading Company Limited may not be concluded by means of e-mail communication.

E-mail transmissions are not secure and Travis Perkins Trading accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins Trading accepts no liability for infection and recommends that you scan this e-mail and any attachments.

-- 
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

Tom Janssens

unread,
Sep 9, 2015, 10:08:29 AM9/9/15
to Behaviour Driven Development
Things that have changed (are persisted) are facts, things that have side-effects need to be verified.

If the first THEN goes wrong, the scenario failed for the wrong reason (i.e. the one you did not plan on verifying), which is bad IMO.

That's why I'm still a fan of a single side-effect generating clause, and would do it like this:

---><8--------------------

Scenario: Save changes to an altered version
Given Alice opened the first version 
And Bob opened the first version 
And Alice saved changes to the first version

When Bob saves changes to the first version

Then the application should start a merge request 

---><8--------------------

FYI I suggested a new prefix "given I did' about a decade ago, to execute scenarios in front of others, but in the end it required too much context:

Scenario: Validate a merge request using my version
Given I did save changes to an altered version
When I validate the merge request using my version
Then ....


Op zaterdag 5 september 2015 13:47:03 UTC+2 schreef Dan North:
Hi Gordon,

Liz.

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsubs...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message.

This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins Trading Company Limited, 733503, Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG or its parent company Travis Perkins plc (Registered in England No. 824821; Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG; VAT number 408556737) and any of its subsidiaries. Agreements binding Travis Perkins Trading Company Limited may not be concluded by means of e-mail communication.

E-mail transmissions are not secure and Travis Perkins Trading accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins Trading accepts no liability for infection and recommends that you scan this e-mail and any attachments.

-- 
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsubs...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message.

This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins Trading Company Limited, 733503, Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG or its parent company Travis Perkins plc (Registered in England No. 824821; Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG; VAT number 408556737) and any of its subsidiaries. Agreements binding Travis Perkins Trading Company Limited may not be concluded by means of e-mail communication.

E-mail transmissions are not secure and Travis Perkins Trading accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins Trading accepts no liability for infection and recommends that you scan this e-mail and any attachments.

-- 
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

Liz Keogh

unread,
Sep 9, 2015, 12:01:34 PM9/9/15
to behaviordriv...@googlegroups.com
Except that part of the rule of a Given is that it shouldn't matter how you got into that state, and there's almost certainly a flag or something being set there that's part of the behaviour you actually care about. Unless you're going to add an awkward scenario to cover *that* behaviour, you're still not illustrating what you really want.

    Given a trade
    When Jane opens a trade for editing
    Then the flag that says it's being edited should be set.

See what I mean?

Liz.

Hi Gordon,

Liz.

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message.

This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins Trading Company Limited, 733503, Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG or its parent company Travis Perkins plc (Registered in England No. 824821; Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG; VAT number 408556737) and any of its subsidiaries. Agreements binding Travis Perkins Trading Company Limited may not be concluded by means of e-mail communication.

E-mail transmissions are not secure and Travis Perkins Trading accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins Trading accepts no liability for infection and recommends that you scan this e-mail and any attachments.

-- 
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message.

This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins Trading Company Limited, 733503, Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG or its parent company Travis Perkins plc (Registered in England No. 824821; Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG; VAT number 408556737) and any of its subsidiaries. Agreements binding Travis Perkins Trading Company Limited may not be concluded by means of e-mail communication.

E-mail transmissions are not secure and Travis Perkins Trading accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins Trading accepts no liability for infection and recommends that you scan this e-mail and any attachments.

-- 
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

Dan North & Associates Ltd, registered in England and Wales, no. 6716833
Registered address: 38 Donnington Road, Worcester Park, KT4 8EN

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

Tom Janssens

unread,
Sep 10, 2015, 2:53:02 AM9/10/15
to Behaviour Driven Development
Fair point; I've probably had an overdose of CQRS lately. ;)

Op woensdag 9 september 2015 18:01:34 UTC+2 schreef Liz Keogh:
Hi Gordon,

Liz.

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsubs...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message.

This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins Trading Company Limited, 733503, Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG or its parent company Travis Perkins plc (Registered in England No. 824821; Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG; VAT number 408556737) and any of its subsidiaries. Agreements binding Travis Perkins Trading Company Limited may not be concluded by means of e-mail communication.

E-mail transmissions are not secure and Travis Perkins Trading accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins Trading accepts no liability for infection and recommends that you scan this e-mail and any attachments.

-- 
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsubs...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message.

This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins Trading Company Limited, 733503, Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG or its parent company Travis Perkins plc (Registered in England No. 824821; Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG; VAT number 408556737) and any of its subsidiaries. Agreements binding Travis Perkins Trading Company Limited may not be concluded by means of e-mail communication.

E-mail transmissions are not secure and Travis Perkins Trading accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins Trading accepts no liability for infection and recommends that you scan this e-mail and any attachments.

-- 
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

Dan North & Associates Ltd, registered in England and Wales, no. 6716833
Registered address: 38 Donnington Road, Worcester Park, KT4 8EN

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

Dave Schinkel

unread,
Sep 20, 2015, 7:32:06 PM9/20/15
to Behaviour Driven Development
To me this starts to to speak to me to split out the 2nd whens into their own scenarios.

To me it's ok to mixe a bunch of them but I think when you start to see a 2nd When, it's a signal to say to split that out into its own scenario.  Kinda like when your'e coding and you start to see things peak out at you, well this starts peaking out at me saying split that out.

Dan North's examples have a bunch of combinations but I don't see 2 Whens in there.  And it makes sense to me that having 2 whens would if I can even say this, break SRP for a scenario lol if that even exists.  Think about it, your scenarios could be doing more than one thing.  I think when you have a 2nd when, that's a signal that it's breaking responsibility in the scenario and the 2nd when deserves its own scenario.

Dave Schinkel

unread,
Sep 20, 2015, 7:32:28 PM9/20/15
to Behaviour Driven Development
for got to post, I was referring to Dan's famous http://dannorth.net/introducing-bdd/ for examples.

Liz Keogh

unread,
Sep 22, 2015, 3:03:02 PM9/22/15
to behaviordriv...@googlegroups.com
Dave,

If you - or anyone else - can take the scenario I proposed and refactor it, without losing the behaviour that's covered by the two "whens", then please do. I'm interested to see what people think. For ease of recollection, it was:

    Given Bob has a trade for $92k of copper open for elaboration
    And Jane has the same trade open too
    When Jane saves it
    And Bob tries to save it
    Then he should be asked if he wants to merge Jane's changes.

Bear in mind that there's something that happens when Jane saves it, the value of which is only exercised when Bob also tries to save it. If you can find a different way to phrase that, please do, even if it's horribly convoluted; I'm interested in having other people try this as I've been musing on it for a while and admit to suffering confirmation bias because human.

Even if we find that I was right (ahem, see above), then I might still find some better ways to talk about it, or some better examples.

I'm also interested in what happens in time-passing scenarios, too; you can see a class-level example of that here. It's a slightly different situation in that the first event could actually be phrased as a given; in this situation it's more about capturing language than the exact capture of any behaviour. Again, for ease of recollection, the scenario (abstract because unit-level, the specific example is the code) is:

    Given an automation element
    When we cause a slow event on that element
    And we wait for the event
    Then we should be notified when the event occurs.

Prizes (or at least a quote in the blog post that I've got pending) for the most thoughtful responses.

Cheers,
Liz.

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

cliff

unread,
Sep 22, 2015, 3:18:45 PM9/22/15
to behaviordriv...@googlegroups.com

I’m sorry if this seems too simple, but couldn’t you just say:

 

Given Bob has a trade for $92K of copper open for elaboration

And Jane has saved the same trade

When Bob tries to save it

Then he should be asked if he wants to merge Jane’s changes

 

Liz Keogh

unread,
Sep 22, 2015, 4:50:41 PM9/22/15
to behaviordriv...@googlegroups.com
Hi Cliff,

This is the first pass, and thank you for making it!

It doesn't work because there are a couple of other rules around Givens:

- It shouldn't matter which order they happen in; they're just a bunch of contexts that exist
- The way in which you set them up shouldn't matter; it should be just as valid to, say, hack the database as to go through the UI (in fact, lots of people use this as a way of making scenarios faster).

So, this doesn't work because the order of the Givens matters, and there's behaviour that happens when Jane saves the trade which isn't being captured in the scenario (probably a save date-time being set on the trade). Hacking that date-time into the database wouldn't actually create the behaviour you're looking for in the application.

This is great stuff, though. Please do keep going. If you can break my example I want to know.

Can we represent it with two scenarios, maybe? That might work, but I haven't found one with an outcome that's valuable on its own...

Cheers,
Liz.

cliff

unread,
Sep 22, 2015, 5:10:11 PM9/22/15
to behaviordriv...@googlegroups.com

The “saved same trade” has to mean something.  At some point before this scenario, I’d imagine there’d have to be:

 

Given Bob has a trade

When he saves it

Then ….

 

This scenario would have to test for the bits that are important when a trade is saved and would define what a “saved trade” looks like.

 

When this works, and the code to successfully rebuild a “saved trade”, it should be sufficient to go with the scenario with Bob and Jane, would it not? 

Liz Keogh

unread,
Sep 22, 2015, 5:28:02 PM9/22/15
to behaviordriv...@googlegroups.com
What does the "Then...." actually look like, for a real example?

I can't find a "Then..." that isn't about the implementation, rather than the problem we're trying to solve; a "Then..." which stands on its own as a valuable outcome.

Can you?

George Dinwiddie

unread,
Sep 22, 2015, 6:18:46 PM9/22/15
to behaviordriv...@googlegroups.com
Liz,

On 9/22/15 3:03 PM, Liz Keogh wrote:
[snip]
> I'm also interested in what happens in time-passing scenarios, too; you
> can see a class-level example of that here
> <https://github.com/lunivore/WiPFlash/blob/master/WiPFlash.Behavior/Framework/WaiterBehaviour.cs>.
> It's a slightly different situation in that the first event could
> actually be phrased as a given; in this situation it's more about
> capturing language than the exact capture of any behaviour. Again, for
> ease of recollection, the scenario (abstract because unit-level, the
> specific example is the code) is:
>
> Given an automation element
> When we cause a slow event on that element
> And we wait for the event
> Then we should be notified when the event occurs.

I'm fond of expressing that as:

Given an automation element
When we cause a slow event on that element
Then we should eventually be notified when the event occurs.

It's an expression I learned from Dale Emery, and it has a few
implementation advantages in addition to what I find a more natural
expression.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

cliff

unread,
Sep 22, 2015, 6:24:06 PM9/22/15
to behaviordriv...@googlegroups.com

Sure, it could be:

 

Then the trade as a save date of today

And the account has XX dollars on hold

And the symbol has been marked as in use

 

These conditions would hopefully include any attributes that are necessary to be set in order to help the second scenario.

Liz Keogh

unread,
Sep 22, 2015, 6:35:50 PM9/22/15
to behaviordriv...@googlegroups.com

Except the class is called "Waiter", and the capability I'm looking at (and therefore the behaviour, and therefore the" when") is the capability to wait for things. That's the method I'm exercising, so it definitely has to be a "when".

But, I'm heartened that you put the slow event as a "when" too; that did also feel right to me and is probably the most controversial line.

Liz Keogh

unread,
Sep 22, 2015, 6:40:54 PM9/22/15
to behaviordriv...@googlegroups.com

Is "the symbol being marked as in use" valuable? Is it something you would ever get from someone when you ask them, "What will you, or your customers, or your systems, be able to do that they can't do right now?"

It doesn't feel like I would ever get that naturally out of a conversation. It feels like compromising the real value I'm looking for.

Please feel free to disagree on this; I'm testing my own thinking here too. What do you think?

George Dinwiddie

unread,
Sep 22, 2015, 8:36:05 PM9/22/15
to behaviordriv...@googlegroups.com
Liz,

On 9/22/15 6:35 PM, Liz Keogh wrote:
> Except the class is called "Waiter", and the capability I'm looking at
> (and therefore the behaviour, and therefore the" when") is the
> capability to wait for things. That's the method I'm exercising, so it
> definitely has to be a "when".

Oh, I didn't notice it was the waiting you were testing. Usually it's
the results from an action that are being tested, and waiting on the
asynchronous ability to test the result is part of the assertion.

See https://github.com/dhemery/hartley/wiki/AssertThat

- George

>
> But, I'm heartened that you put the slow event as a "when" too; that did
> also feel right to me and is probably the most controversial line.
>
> On 22 Sep 2015 11:18 pm, "George Dinwiddie" <li...@idiacomputing.com
> <mailto:behaviordrivendevelopment%2Bunsu...@googlegroups.com>.
> To post to this group, send email to
> behaviordriv...@googlegroups.com
> <mailto:behaviordriv...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google
> Groups "Behaviour Driven Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to behaviordrivendeve...@googlegroups.com
> <mailto:behaviordrivendeve...@googlegroups.com>.
> To post to this group, send email to
> behaviordriv...@googlegroups.com
> <mailto:behaviordriv...@googlegroups.com>.

Liz Keogh

unread,
Sep 23, 2015, 1:58:43 AM9/23/15
to behaviordriv...@googlegroups.com

Yep, this is essentially a class that makes the asynchronous waiting easy (and I've used this "waiting" pattern in other automation frameworks too).

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.
To post to this group, send email to behaviordriv...@googlegroups.com.

aslak hellesoy

unread,
Sep 23, 2015, 2:15:00 AM9/23/15
to behaviordriv...@googlegroups.com


On Tuesday, September 22, 2015, Liz Keogh <l...@lunivore.com> wrote:
Hi Cliff,

This is the first pass, and thank you for making it!

It doesn't work because there are a couple of other rules around Givens:

- It shouldn't matter which order they happen in; they're just a bunch of contexts that exist

This is the first time I hear about this rule. It sounds interesting, but also a bit too strict.

Where does this rule come from Liz?

Liz Keogh

unread,
Sep 23, 2015, 2:37:41 AM9/23/15
to behaviordriv...@googlegroups.com


On 23 Sep 2015 7:14 am, "aslak hellesoy" <aslak.h...@gmail.com> wrote:
>
>
>
> On Tuesday, September 22, 2015, Liz Keogh <l...@lunivore.com> wrote:
>>
>> Hi Cliff,
>>
>> This is the first pass, and thank you for making it!
>>
>> It doesn't work because there are a couple of other rules around Givens:
>>
>> - It shouldn't matter which order they happen in; they're just a bunch of contexts that exist
>
>
> This is the first time I hear about this rule. It sounds interesting, but also a bit too strict.
>
> Where does this rule come from Liz?

Derived by me from the rule that the behaviour you're interested in should be in the "when"; if the order in which Givens are set up matters then it's because there's behaviour that matters.

Dan also mentioned this a few posts back.

The rule that it shouldn't matter how you got to the context has been around for a while.

As with all BDD, we can be pragmatic about this; I'm saying "rule" where I should probably say "guideline"... but it makes way more sense to me than the rule that there should only be one "when", in these situations. (Where did that one come from, anyway?)

Cheers,
Liz.

aslak hellesoy

unread,
Sep 23, 2015, 4:20:37 AM9/23/15
to behaviordriv...@googlegroups.com
On Wed, Sep 23, 2015 at 7:37 AM, Liz Keogh <l...@lunivore.com> wrote:


On 23 Sep 2015 7:14 am, "aslak hellesoy" <aslak.h...@gmail.com> wrote:
>
>
>
> On Tuesday, September 22, 2015, Liz Keogh <l...@lunivore.com> wrote:
>>
>> Hi Cliff,
>>
>> This is the first pass, and thank you for making it!
>>
>> It doesn't work because there are a couple of other rules around Givens:
>>
>> - It shouldn't matter which order they happen in; they're just a bunch of contexts that exist
>
>
> This is the first time I hear about this rule. It sounds interesting, but also a bit too strict.
>
> Where does this rule come from Liz?

Derived by me from the rule that the behaviour you're interested in should be in the "when"; if the order in which Givens are set up matters then it's because there's behaviour that matters.

Dan also mentioned this a few posts back.

The rule that it shouldn't matter how you got to the context has been around for a while.

I really like it. I think I've been intuitively following this guideline for a while, and I can see how it can be incredibly useful to beginners.

People who are new to BDD (especially with a testing background) tend to save Given I'm non this page And I follow this link And this And that. Not independent in the least bit.
If they strive to follow this guideline I think it could help them come up with something more declarative, with better documentation value.

Thanks for sharing

As with all BDD, we can be pragmatic about this; I'm saying "rule" where I should probably say "guideline"... but it makes way more sense to me than the rule that there should only be one "when", in these situations. (Where did that one come from, anyway?)

Cheers,
Liz.

--

Andrew Premdas

unread,
Sep 24, 2015, 1:33:31 AM9/24/15
to behaviordriv...@googlegroups.com
Given an automation element
And a slow event in progress on that element
When we wait until the event is complete
Then we should see the completed event

I think this would be better if we had a real example (automation element, what is that!). Also it would be better if we wrote a scenario title as this defines what we are interested in e.g.

  Scenario: Waiting for the completion of an automation element

Just because an action is in progress, doesn't mean it can't be a Given. Our When is about what our scenario is interested in, not the mechanism of how we get there.

Anyhow my 2c :)

--
------------------------
Andrew Premdas

Liz Keogh

unread,
Sep 24, 2015, 2:26:32 AM9/24/15
to behaviordriv...@googlegroups.com

Hi Andrew,

Specific example is in the original link along with the title (because it's unit-level, the specific example is the code - this is just how I do it; not remotely suggesting that it's the only way here).

Having said that, what would you write instead?

(Link again for ease of access: https://github.com/lunivore/WiPFlash/blob/master/WiPFlash.Behavior/Framework/WaiterBehaviour.cs )

Liz.

Andrew Premdas

unread,
Sep 24, 2015, 3:34:41 PM9/24/15
to behaviordriv...@googlegroups.com
Thanks for link Liz.

Personally I would make your first `when` an and (so it becomes a Given) and then just have the one 'when'. But I think its a very small difference.

I don't think I agree with the rule that Given's must be able to be run in any order, I think its perfectly reasonable for one given to refer to another and even depend on state from another Given, e.g.

  Given there is a user Frank
  And Frank is signed in

and that using

  Given Frank is signed in

on its own would blow up.

I wonder if abstraction level effects this, perhaps when using GWT in lower level tests the Given is an isolated context rule has greater value.

All best


Dan North

unread,
Sep 24, 2015, 4:31:52 PM9/24/15
to behaviordriv...@googlegroups.com
I don’t think of it as “any order”. It’s more like this:

Given [the world is in some state]
When [something interesting happens]
Then [the world should be in some new state]

For the givens I don’t want to have to care about how the world got into that state, all I’m interested in is exercising the application once it is there. If you poke data into a database, fake out some dependent systems, set me up a complete Truman world, I’m ok with all of that if I can’t tell the difference.

For the when(s) I do care. I want to interact with the system the same way anyone else would. I’m testing the behaviour of the application from the perspective of a stakeholder. So I need to use the application the same way the stakeholder would.

For the thens, again I don’t care how you verify the outcome, just that you can tell whether it worked the way you expected.

If there is some subtle interaction between the givens you are forcing me to care about them, which is cognitive load I don’t need. Liz’s “any order” constraint addresses this but might be a bit extreme. My criteria is simply "don’t make me care”!

Cheers,
Dan

Andrew Premdas

unread,
Sep 24, 2015, 9:52:34 PM9/24/15
to behaviordriv...@googlegroups.com
I don't think in this context there is any subtle interaction in the Givens, rather that the state you are getting into is better described using two statements rather than one. Sometimes it is clearer to describe the path to a particular state in multiple short statements.

In Liz's example if you see the 'slow event in progress' as part of the something interesting that is happening then you will write the scenario as she has. I see the slow event as part of something that puts the world in a particular state, hence the difference.

All best

Liz Keogh

unread,
Sep 25, 2015, 1:53:09 PM9/25/15
to behaviordriv...@googlegroups.com
That's a better way of putting it; thanks Dan!

Tom Janssens

unread,
Sep 26, 2015, 3:18:54 AM9/26/15
to Behaviour Driven Development
I might be missing something obvious here, but first you talk about the fact that the order of givens shouldn't matter:

    Given Bob has a trade for $92k of copper open for elaboration
    And Jane has the same trade open too
    When Jane saves it
    And Bob tries to save it
    Then he should be asked if he wants to merge Jane's changes.

That feels odd to me, because your second given depends on your first. If you want to respect that rule, you'd have to do it like this

Given Bob and Alice opened a trade for 92k of copper for elaboration, Bob confirmed the trade and Alice also tries to confirm
When Alice confirms the trade
She should be asked to merge the trade

Anyway, I think we might be talking about details here. TBH I understand where the rule comes from: givens should never fail, and if they depend on each other, they might change.

Maybe we could have some kind of convention which somehow implies that givens depend on eachother (i.e. use a "Given"  for each new sentence and an "and" for dependent facts)

    Given Bob has a trade for $92k of copper open for elaboration
    And Jane has the same trade open too.
    Given the blahblahblah...
    When Jane saves it
    And Bob tries to save it
    Then he should be asked if he wants to merge Jane's changes.
 

Op dinsdag 22 september 2015 21:03:02 UTC+2 schreef Liz Keogh:
Dave,

To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.

To post to this group, send email to behaviordriv...@googlegroups.com.
Visit this group at http://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

Liz Keogh

unread,
Sep 26, 2015, 6:35:26 AM9/26/15
to behaviordriv...@googlegroups.com
Hi Tom,

You could swap Bob and Jane round in my example; it wouldn't matter who opened it first. The only thing that matters is who saved it first.

I prefer Dan's way of expressing this now anyway, so please forget my "rule" - part of the reason for doing this was to explore. But, as Dan said with respect to givens, "Don't make me care". In your first example, again, there's behaviour happening when Bob saves the trade, which isn't being captured (or, if it is, because it's behaviour you care about, then it should be a "when", not a "given").

Cheers,
Liz.

Dave,