Multiple given,when and then in a feature file.

[Neethu V.M]

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]

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]

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.

--

http://www.facebook.com/reinaldo | http://twitter.com/rnsanches

[Gordon Mullan]

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.

--

http://www.facebook.com/reinaldo | http://twitter.com/rnsanches

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]

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.

--

http://www.facebook.com/reinaldo | http://twitter.com/rnsanches

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.

--

Liz Keogh
l...@lunivore.com
http://lizkeogh.com
http://lunivore.com

[Gordon Mullan]

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.

--

http://www.facebook.com/reinaldo | http://twitter.com/rnsanches

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]

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

+44 (0)7580 099876

d...@dannorth.net

http://dannorth.net

@tastapod

Dan North & Associates Ltd, registered in England and Wales, no. 6716833

Registered address: 38 Donnington Road, Worcester Park, KT4 8EN

[Gordon Mullan]

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.

-- 

http://www.facebook.com/reinaldo | http://twitter.com/rnsanches

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.

-- 

Liz Keogh
l...@lunivore.com
http://lizkeogh.com
http://lunivore.com

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]

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.

-- 

http://www.facebook.com/reinaldo | http://twitter.com/rnsanches

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.

-- 

Liz Keogh
l...@lunivore.com
http://lizkeogh.com
http://lunivore.com

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]

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.

-- 

http://www.facebook.com/reinaldo | http://twitter.com/rnsanches

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
l...@lunivore.com
http://lizkeogh.com
http://lunivore.com

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

+44 (0)7580 099876

d...@dannorth.net

http://dannorth.net

@tastapod

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]

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.

-- 

http://www.facebook.com/reinaldo | http://twitter.com/rnsanches

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.

-- 

Liz Keogh
l...@lunivore.com
http://lizkeogh.com
http://lunivore.com

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

+44 (0)7580 099876

d...@dannorth.net

http://dannorth.net

@tastapod

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]

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]

for got to post, I was referring to Dan's famous http://dannorth.net/introducing-bdd/ for examples.

[Liz Keogh]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

> Visit this group at
> http://groups.google.com/group/behaviordrivendevelopment.
> For more options, visit https://groups.google.com/d/optout.
>

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

> Visit this group at
> http://groups.google.com/group/behaviordrivendevelopment.
> For more options, visit https://groups.google.com/d/optout.

[Liz Keogh]

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]

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]

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]

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]

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

blog.andrew.premdas.org

[Liz Keogh]

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]

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]

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]

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]

That's a better way of putting it; thanks Dan!

[Tom Janssens]

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]

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,

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.

--

Liz Keogh
l...@lunivore.com
http://lizkeogh.com
http://lunivore.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.

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.

[Andrew Premdas]

I think its a bit odd to say 'don't make me care' about any part of a scenario. Givens are obviously crucial to a scenario because they set up the environment we want to explore with the 'when'; 'thens' are equally important because they prove/disprove what happens in the 'when'.

When you write a scenario you shouldn't care about how the scenario is implemented, the focus should be on using language eloquently and stating intention with clarity. If scenarios are well implemented their really is no need to think about existing implementations when 'writing' new scenarios. The time to think about existing implementations is when you implement the scenario. Implementing a scenario is an entirely different thing to writing a scenario. At the point of implementation you have a number of options to make a new scenario fit elegantly into the existing features.

All best

Andrew

------------------------

Andrew Premdas

blog.andrew.premdas.org

[Liz Keogh]

Hi Andrew,

> the focus should be on using language eloquently and stating intention with clarity

Right, which is why we have the separation between contexts and events. If something you're doing has behaviour you need to care about then it *is* an event, not a context. A context is just the state in which the scenario starts, otherwise it's more than just a context.

So far, nobody has been able to rewrite that scenario to use only one "when", while still capturing the important behaviour, without resorting to a split with an inelegant joining outcome / context that has no independent value, or hiding the behaviour in a " given", which I consider to be worse than using two "when's" as it violates an even more crucial guideline.

So I'm sticking to my two "when's".

Cheers,
Liz.

[Andrew Premdas]

On 29 September 2015 at 08:38, Liz Keogh <l...@lunivore.com> wrote:

Hi Andrew,

> the focus should be on using language eloquently and stating intention with clarity

Right, which is why we have the separation between contexts and events. If something you're doing has behaviour you need to care about then it *is* an event, not a context. A context is just the state in which the scenario starts, otherwise it's more than just a context.

So far, nobody has been able to rewrite that scenario to use only one "when", while still capturing the important behaviour, without resorting to a split with an inelegant joining outcome / context that has no independent value, or hiding the behaviour in a " given", which I consider to be worse than using two "when's" as it violates an even more crucial guideline.

So I'm sticking to my two "when's".

Cheers,
Liz.

A context is the state the scenario starts! The 'just' diminishes its importance. Any behaviour is dependent on context, so how you describe the context is just as important as how you describe the behaviour. Perhaps because I see Givens and Whens as equals, I have less issues with making your first When a Given and expressing the scenario in that way.

All best

Andrew

[Liz Keogh]

On Tue, Sep 29, 2015 at 5:51 PM, Andrew Premdas <apre...@gmail.com> wrote:

On 29 September 2015 at 08:38, Liz Keogh <l...@lunivore.com> wrote:

Hi Andrew,

> the focus should be on using language eloquently and stating intention with clarity

Right, which is why we have the separation between contexts and events. If something you're doing has behaviour you need to care about then it *is* an event, not a context. A context is just the state in which the scenario starts, otherwise it's more than just a context.

So far, nobody has been able to rewrite that scenario to use only one "when", while still capturing the important behaviour, without resorting to a split with an inelegant joining outcome / context that has no independent value, or hiding the behaviour in a " given", which I consider to be worse than using two "when's" as it violates an even more crucial guideline.

So I'm sticking to my two "when's".

Cheers,
Liz.

A context is the state the scenario starts! The 'just' diminishes its importance. Any behaviour is dependent on context, so how you describe the context is just as important as how you describe the behaviour. Perhaps because I see Givens and Whens as equals, I have less issues with making your first When a Given and expressing the scenario in that way.

...except that, if you put behaviour that you care about in the context, then the state in which the scenario starts isn't expressed by the Givens. It's expressed by the Givens that happen before the behaviour you care about, which isn't all of them, and the outcome isn't driven by just the events happening in that context; it's driven by something hidden within the context too.

In that situation, it makes it really, really hard to discuss other scenarios which have the same events, or other outcomes which are important. It makes it harder to question whether the behaviour really should work that way. In other words, it makes it harder to have conversations about that scenario. (More on conversational patterns here.)

And that's without talking about the difficulty of maintaining it, three months or three years later.

Cheers,

Liz. 

[Andrew Premdas]

Perhaps all Givens are existing behaviour that has been explored in other scenarios, I know most of mine are, and I'm not sure I can think of a counter example at the moment. This would suggest that if you need two 'whens', you perhaps could/should create an additional scenario that explores the first when. Indeed it might suggest that you might already have scenarios that cover this area. In your trading example you would expect to have scenarios that deal with people opening and saving trades, before you explore the interaction between two users interacting on the same trade. In a similar way with you petstore example I would hope that you had scenarios about choosing petfood types, or choosing automation elements (why are we talking about automation elements here?) before you wrote your scenarios about slow elements.

I'd suggest that the only way to get to a particular state is to exercise existing behaviour.

I'd also suggest that there is nothing in our conversation so far that suggests that one approach makes things 'really really easy' and the other approach makes things 'really really hard', or that what I do is any more or less maintainable than what you are doing.

All best

Andrew

--

Liz Keogh
l...@lunivore.com
http://lizkeogh.com
http://lunivore.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.
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]

--

Typed with thumbs, please excuse errors.

On 30 Sep 2015, at 04:28, Andrew Premdas <apre...@gmail.com> wrote:

On 29 September 2015 at 19:37, Liz Keogh <l...@lunivore.com> wrote:

On Tue, Sep 29, 2015 at 5:51 PM, Andrew Premdas <apre...@gmail.com> wrote:

On 29 September 2015 at 08:38, Liz Keogh <l...@lunivore.com> wrote:

Hi Andrew,

> the focus should be on using language eloquently and stating intention with clarity

Right, which is why we have the separation between contexts and events. If something you're doing has behaviour you need to care about then it *is* an event, not a context. A context is just the state in which the scenario starts, otherwise it's more than just a context.

So far, nobody has been able to rewrite that scenario to use only one "when", while still capturing the important behaviour, without resorting to a split with an inelegant joining outcome / context that has no independent value, or hiding the behaviour in a " given", which I consider to be worse than using two "when's" as it violates an even more crucial guideline.

So I'm sticking to my two "when's".

Cheers,
Liz.

A context is the state the scenario starts! The 'just' diminishes its importance. Any behaviour is dependent on context, so how you describe the context is just as important as how you describe the behaviour. Perhaps because I see Givens and Whens as equals, I have less issues with making your first When a Given and expressing the scenario in that way.

...except that, if you put behaviour that you care about in the context, then the state in which the scenario starts isn't expressed by the Givens. It's expressed by the Givens that happen before the behaviour you care about, which isn't all of them, and the outcome isn't driven by just the events happening in that context; it's driven by something hidden within the context too.

In that situation, it makes it really, really hard to discuss other scenarios which have the same events, or other outcomes which are important. It makes it harder to question whether the behaviour really should work that way. In other words, it makes it harder to have conversations about that scenario. (More on conversational patterns here.)

And that's without talking about the difficulty of maintaining it, three months or three years later.

Cheers,

Liz. 

Perhaps all Givens are existing behaviour that has been explored in other scenarios,

Not quite. Givens are an expression of current state, the Context for the scenario. They say what is true or what has happened. They don't have an opinion about behaviour so ideally they should be worded in state rather than behavioural terms (h/t Liz's conversational patterns).

You are welcome to implement them using existing application behaviour, or to pop the hood and just directly manipulate data, dependencies or other application state.

The event, the When, is strictly behavioural. It should interact with the application just like the respective stakeholder(s) would, otherwise we aren't exercising any behaviour.

The Thens are also about state rather than behaviour, but this time verifying that the system was affected in he expected way, better yet that it wasn't in an unexpected way.

I would probably have a number of end-to-end run-throughs that chain a sequence of scenarios, to use as smoke tests. In that case one scenario might well set up the world in a suitable state for the next one, but other than that each scenario is at liberty to set up the world in whichever way it chooses.

Cheers,

Dan

[Andrew Premdas]

On 30 September 2015 at 13:00, Dan North <d...@dannorth.net> wrote:

--

Typed with thumbs, please excuse errors.

On 30 Sep 2015, at 04:28, Andrew Premdas <apre...@gmail.com> wrote:

On 29 September 2015 at 19:37, Liz Keogh <l...@lunivore.com> wrote:

On Tue, Sep 29, 2015 at 5:51 PM, Andrew Premdas <apre...@gmail.com> wrote:

On 29 September 2015 at 08:38, Liz Keogh <l...@lunivore.com> wrote:

Hi Andrew,

> the focus should be on using language eloquently and stating intention with clarity

Right, which is why we have the separation between contexts and events. If something you're doing has behaviour you need to care about then it *is* an event, not a context. A context is just the state in which the scenario starts, otherwise it's more than just a context.

So far, nobody has been able to rewrite that scenario to use only one "when", while still capturing the important behaviour, without resorting to a split with an inelegant joining outcome / context that has no independent value, or hiding the behaviour in a " given", which I consider to be worse than using two "when's" as it violates an even more crucial guideline.

So I'm sticking to my two "when's".

Cheers,
Liz.

A context is the state the scenario starts! The 'just' diminishes its importance. Any behaviour is dependent on context, so how you describe the context is just as important as how you describe the behaviour. Perhaps because I see Givens and Whens as equals, I have less issues with making your first When a Given and expressing the scenario in that way.

...except that, if you put behaviour that you care about in the context, then the state in which the scenario starts isn't expressed by the Givens. It's expressed by the Givens that happen before the behaviour you care about, which isn't all of them, and the outcome isn't driven by just the events happening in that context; it's driven by something hidden within the context too.

In that situation, it makes it really, really hard to discuss other scenarios which have the same events, or other outcomes which are important. It makes it harder to question whether the behaviour really should work that way. In other words, it makes it harder to have conversations about that scenario. (More on conversational patterns here.)

And that's without talking about the difficulty of maintaining it, three months or three years later.

Cheers,

Liz. 

Perhaps all Givens are existing behaviour that has been explored in other scenarios,

Not quite. Givens are an expression of current state, the Context for the scenario. They say what is true or what has happened. They don't have an opinion about behaviour so ideally they should be worded in state rather than behavioural terms (h/t Liz's conversational patterns).

My point was that to get to any state you have to exercise some existing behaviour. e.g. If you want to set the context that I have logged in, you must have the behaviour that someone can login. So I'd expect you to already have a scenario with

  When I login

and then you would use that behaviour in

  Given I am logged in.

An important point here is that by 'use that behaviour' I DO NOT mean use the existing test code that exercises that behaviour, I just mean use in any way you choose the applications ability to log users in. (this includes short cutting directly to the databse if you must, but a well designed application should rarely require this.)

I'd be interested to know how When's express opinions about behaviour. It seems to me that When's just describe behaviour e.g. 'When I login, and only in combination with a Then can an opinion be formed e.g. Then I should be logged in

All best

Andrew

[Dan North]

On 30 Sep 2015, at 13:53, Andrew Premdas <apre...@gmail.com> wrote:

On 30 September 2015 at 13:00, Dan North <d...@dannorth.net> wrote:

--

Typed with thumbs, please excuse errors.

On 30 Sep 2015, at 04:28, Andrew Premdas <apre...@gmail.com> wrote:

On 29 September 2015 at 19:37, Liz Keogh <l...@lunivore.com> wrote:

On Tue, Sep 29, 2015 at 5:51 PM, Andrew Premdas <apre...@gmail.com> wrote:

On 29 September 2015 at 08:38, Liz Keogh <l...@lunivore.com> wrote:

Hi Andrew,

> the focus should be on using language eloquently and stating intention with clarity

Right, which is why we have the separation between contexts and events. If something you're doing has behaviour you need to care about then it *is* an event, not a context. A context is just the state in which the scenario starts, otherwise it's more than just a context.

So far, nobody has been able to rewrite that scenario to use only one "when", while still capturing the important behaviour, without resorting to a split with an inelegant joining outcome / context that has no independent value, or hiding the behaviour in a " given", which I consider to be worse than using two "when's" as it violates an even more crucial guideline.

So I'm sticking to my two "when's".

Cheers,
Liz.

A context is the state the scenario starts! The 'just' diminishes its importance. Any behaviour is dependent on context, so how you describe the context is just as important as how you describe the behaviour. Perhaps because I see Givens and Whens as equals, I have less issues with making your first When a Given and expressing the scenario in that way. 

...except that, if you put behaviour that you care about in the context, then the state in which the scenario starts isn't expressed by the Givens. It's expressed by the Givens that happen before the behaviour you care about, which isn't all of them, and the outcome isn't driven by just the events happening in that context; it's driven by something hidden within the context too.

In that situation, it makes it really, really hard to discuss other scenarios which have the same events, or other outcomes which are important. It makes it harder to question whether the behaviour really should work that way. In other words, it makes it harder to have conversations about that scenario. (More on conversational patterns here.)

And that's without talking about the difficulty of maintaining it, three months or three years later.

Cheers,

Liz. 

Perhaps all Givens are existing behaviour that has been explored in other scenarios, 

Not quite. Givens are an expression of current state, the Context for the scenario. They say what is true or what has happened. They don't have an opinion about behaviour so ideally they should be worded in state rather than behavioural terms (h/t Liz's conversational patterns).

My point was that to get to any state you have to exercise some existing behaviour.

And my counter is not necessarily.

Liz wrote a post a while ago called something like “Don’t start with Login”. The fact that you are logged in simply means there is some application state that says this. All we need for that is to have modelled (for now) how that application state will look. There is no prerequisite that the behaviour around login even exists yet.

This is quite a liberating observation. It means you can start development anywhere in the middle of a user journey, and choose to optimise for discovery and surfacing uncertainty rather than starting at the beginning and having to implement each piece in order.

e.g. If you want to set the context that I have logged in, you must have the behaviour that someone can login. So I'd expect you to already have a scenario with

  When I login

and then you would use that behaviour in 

  Given I am logged in.

Nope. Just a table with (user_id, logged_in). Or an in-memory set, or something.

An important point here is that by 'use that behaviour' I DO NOT mean use the existing test code that exercises that behaviour, I just mean use in any way you choose the applications ability to log users in. (this includes short cutting directly to the databse if you must, but a well designed application should rarely require this.)

Again I’m going to disagree. The ability to set up a scenario quickly is orthogonal to the application quality. I will probably end up with helpers for the scenarios that make the common quick-and-dirty setup cases even quicker.

I'd be interested to know how When's express opinions about behaviour. It seems to me that When's just describe behaviour e.g. 'When I login, and only in combination with a Then can an opinion be formed e.g. Then I should be logged in

"When I log in” is an opinion. It says logging in is how you get authorisation around here, rather than just having the doors wide open or restricting access based on e.g. an IP address or persisted token.

“Then I should be logged in” is verification of that opinion.

We are mostly arguing semantics at this point, but the important distinction is that implementing behaviour doesn’t need to happen in the narrative order of that behaviour. You can jump right in to the piece you think it will be most useful to go next, and fake anything you need upstream of it. My definition of “useful” is whether it will surface assumptions or missing pieces, reduce risk or provide a quick win that I can show to my stakeholders to get feedback.

Cheers,

Dan

[Gordon Mullan]

"...the important distinction is that implementing behaviour doesn’t need to happen in the narrative order of that behaviour."

Love that observation Dan - thanks!

All best

Andrew

 

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.

-- 

------------------------

Andrew Premdas

blog.andrew.premdas.org

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

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

-- 

------------------------

Andrew Premdas

blog.andrew.premdas.org

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

[Andrew Premdas]

Thats fine, but I think having scenarios in the codebase that pass, and that say some functionality exists when it doesn't is a risky practice. I'm happy for people to think about these scenarios, write them and store them somewhere else though.

Say we have a scenario that wants to end up using login

Given I have registered my pet fluffy

And Jill has registered her pet womble

When I view my pets

Then I should see fluffy

And I should not see womble

Now you could put this in you codebase and implement the first two givens as no-ops, and hard code fluffy in the view and make the scenario pass. But personally I would not be happy commiting that code. Instead I would write some scenarios to get me on the way e.g.

When I register my pet fluffy

Then fluffy should be registered

and

When I view my pets

Then I should see my pets

Now gradually we can move to a state where we have the functionality to implement the first scenario, but on our journey, by breaking things down into smaller components we give ourselves the opportunity to learn and explore the behaviour.

At any point in the development of an application I believe that the passing scenarios should reflect the current state of the application, and so in this context, 'to get to a particular state you have to exercise some existing behaviour'.

e.g. If you want to set the context that I have logged in, you must have the behaviour that someone can login. So I'd expect you to already have a scenario with

  When I login

and then you would use that behaviour in 

  Given I am logged in.

Nope. Just a table with (user_id, logged_in). Or an in-memory set, or something.

The way I see things having such a table is having the ability to login, so writing stuff to the table is using that behaviopur.

An important point here is that by 'use that behaviour' I DO NOT mean use the existing test code that exercises that behaviour, I just mean use in any way you choose the applications ability to log users in. (this includes short cutting directly to the databse if you must, but a well designed application should rarely require this.)

Again I’m going to disagree. The ability to set up a scenario quickly is orthogonal to the application quality. I will probably end up with helpers for the scenarios that make the common quick-and-dirty setup cases even quicker.

Writing directly to the database isn't DRY and bypasses the applications control of the database. Quick setups that bypass business rules (both current and future) cause significant problems as the application grows, and business rules develop. In addition its so simple to fix this, just have the application do the work for you, by writing a simple service that the application uses to create the user and that your tests can also use to create the user.

I'd be interested to know how When's express opinions about behaviour. It seems to me that When's just describe behaviour e.g. 'When I login, and only in combination with a Then can an opinion be formed e.g. Then I should be logged in

"When I log in” is an opinion. It says logging in is how you get authorisation around here, rather than just having the doors wide open or restricting access based on e.g. an IP address or persisted token.

“Then I should be logged in” is verification of that opinion.

We are mostly arguing semantics at this point, but the important distinction is that implementing behaviour doesn’t need to happen in the narrative order of that behaviour. You can jump right in to the piece you think it will be most useful to go next, and fake anything you need upstream of it. My definition of “useful” is whether it will surface assumptions or missing pieces, reduce risk or provide a quick win that I can show to my stakeholders to get feedback.

Nothing I've said should have conveyed the idea that implementing behaviour should have to happen in the narrative order of the behaviour. My apologies for not being clear enough on that. I completely agree with you and Liz, that we don't need to start with login.

All best

Andrew

<snip>

[George Dinwiddie]

Andrew,

I tend to agree with Dan on this. I'd let him step in, but there is far
more that bothers me about the scenarios you suggest than the login
question.

On 10/5/15 12:28 PM, Andrew Premdas wrote:
[snip]

>
>
> Thats fine, but I think having scenarios in the codebase that pass, and
> that say some functionality exists when it doesn't is a risky practice.
> I'm happy for people to think about these scenarios, write them and
> store them somewhere else though.
>
> Say we have a scenario that wants to end up using login
>
> Given I have registered my pet fluffy
> And Jill has registered her pet womble
> When I view my pets
> Then I should see fluffy
> And I should not see womble

I've come to regard this first-person viewpoint as an anti-pattern in
executable specifications. To me, it's akin to the Transaction Model in
Martin Fowler's Patterns of Enterprise Application Software, in that
it's a quick and easy way to get started, but soon gets in your way.
Similar to the way that a Domain Model helps build a smaller, more
robust application for the long term, a third-person viewpoint helps you
create a description that is more informative and will help you, or
whomever, when you look at this again 6 months from now.

What role and "I" playing in this scenario? Why is the scenario
specifying what "I should see" or not see rather than specifying the
behavior of the system? What if the UI changes so it's no longer visual
(using a screen-reader, perhaps).

Consider

Scenario: authenticated users see their registered pets but not others
Given Andrew has registered his pet Fluffy
And Jill has registered her pet Womble
When Andrew views "my pets"
Then the system presents Fluffy
And the system does not present Womble

In the above, you can consider Andrew to be authenticated when viewing
"my pets" because otherwise the system would have no way to know it was
Andrew. If the scenario was dealing with an unauthenticated user, I'd
likely say
When an unknown person views "my pets"

If you don't like this assumption, you can make it explicit
Scenario: authenticated users see their registered pets but not others
Given Andrew has registered his pet Fluffy
And Jill has registered her pet Womble
When authenticated user Andrew views "my pets"
Then the system presents Fluffy
And the system does not present Womble

and the unknown user could be
When an unauthenticated person views "my pets"

>
> Now you could put this in you codebase and implement the first two
> givens as no-ops, and hard code fluffy in the view and make the scenario
> pass. But personally I would not be happy commiting that code. Instead I
> would write some scenarios to get me on the way e.g.
>
> When I register my pet fluffy
> Then fluffy should be registered
>
> and
>
> When I view my pets
> Then I should see my pets

I don't like either of these, as they seem like tautologies that don't
tell me anything about how the system behaves.

>
> Now gradually we can move to a state where we have the functionality to
> implement the first scenario, but on our journey, by breaking things
> down into smaller components we give ourselves the opportunity to learn
> and explore the behaviour.
>
> At any point in the development of an application I believe that the
> passing scenarios should reflect the current state of the application,
> and so in this context, 'to get to a particular state you have to
> exercise some existing behaviour'.

I don't want my scenarios to assume unrelated behavior. It's fine for
the system to make that assumption, but I'd rather declare the state
rather than the means to achieve that state. And there may be more than
one way to reach that state. When the system is implemented using a
Domain Model, it can be pretty easy to go directly to the state. When
implementing using a Transaction Model, then there may be many subtle
variations depending on the path you take to get there.

[snip]

[George Dinwiddie]

P.S. This is the topic of the talk I'm giving at the British Computer
Society in London on November 6, 18:00.

- George