Specific scenario or generic scenario with reusable steps. Advice asked!

66 views
Skip to first unread message

Jeroen Vis

unread,
Feb 27, 2019, 7:49:41 AM2/27/19
to Specification by Example
I need advice on how to write scenarios. First I have to explain that we have a CQRS architecture where commands and queries are separated APIs. We specify the commands with Gherkin scenarios that are used in Specflow to create tests.

In the scenarios below the domain is that of Expenses. An expense bundle is a collection of expenses. With this scenario I want to specify and test that I can't create an expense for an expense bundle that someone else created. I can only create expenses for an expenses bundle that I created.

The following approach is that I try to reuse as many steps as possible:

Scenario: Not allowed to create expense for a bundle that was created by another declarant
Given the following expense bundles exist
| declarant | name | administration | status |
| Lucy | Trip to New York | Company B.V. | not submitted |
When I create an expense for the following expense bundle
| declarant | name | administration | status |
| Lucy | Trip to New York | Company B.V. | not submitted |
Then the expense is not created for the expense bundle

The name, administration and status is maybe not relevant in above example. But in other scenario's I can reuse the 'given the following expense bundles exist' step. This saves time for the developer.

In the following approach I try to write a scenario that is better readable and more specific:

Scenario: Not allowed to create expense for a bundle that was created by another declarant
When I create an expense for an expense bundle that was created by another declarant
Then the expense is not created for the expense bundle

In this case the developer has to write a When step that will probably never be used again. Is this a problem?

I'm struggling with both options a lot in my scenarios. Any advice?

Jeroen Vis

unread,
Feb 27, 2019, 7:55:22 AM2/27/19
to Specification by Example
Good to know is that both scenarios have a background that the user that performs the commands is another user than the user that created the bundle

Background: Submit expense authorization
Given I am declarant 'Marieke'

Nigel Charman

unread,
Feb 28, 2019, 3:46:52 AM2/28/19
to Specification by Example
Hi Jeroen

I would encourage you to write the generic rule as an acceptance criteria or business rule, stated as part of the Description block of the feature file. The specific scenario(s) would then illustrate and test instances of the generic rule. I find that using specific details in the scenario gets people to ask "what if ..." and question other cases in ways that generic rules don't. 


Nigel

Jeroen Vis

unread,
Feb 28, 2019, 4:52:37 AM2/28/19
to Specification by Example
Thanks for your answer and for your blog. Very interesting. 
I'm not doing Specification by Example when I'm specifying my scenario in a generic way.

Gojko Adzic

unread,
Mar 1, 2019, 5:56:05 AM3/1/19
to specificati...@googlegroups.com
Hi Jeroen,

I generally advise against optimising scenarios for reuse. It's good to evolve a consistent domain model/language, and that will lead to some common scenario blocks useful in various places, but doing a scenario in a particular way just because it's easier to reuse steps is generally a bad idea. This is because you start describing how something is tested instead of what's being tested, and six months down the line it becomes a maintenance nightmare. 

separating "what" and "how" is one of the key success patterns for scenarios in tools like specflow. push reuse one or two levels below (fixture code implementing the steps, classes that that code reuses). this gives you compile time support for refactoring, intellisense and a lot more.

going back to your particular example, "The name, administration and status is maybe not relevant in above example." - so what is? what makes one expense bundle the same as the other? point that out to make it clear. that's one of the benefits of using a text layer on top of code, to make important things really clear. then show with some boundary examples what is OK or not OK. 
eg what if Tommy tries declaring expenses for trip to new york; what if tommy declares it but for a different date? how different does the date need to be? what if lucy declares it on a different date. what if it's a different name but same date/company.

--
You received this message because you are subscribed to the Google Groups "Specification by Example" group.
To unsubscribe from this group and stop receiving emails from it, send an email to specificationbyex...@googlegroups.com.
To post to this group, send email to specificati...@googlegroups.com.
Visit this group at https://groups.google.com/group/specificationbyexample.
For more options, visit https://groups.google.com/d/optout.

Jeroen Vis

unread,
Mar 1, 2019, 9:17:08 AM3/1/19
to Specification by Example
Thanks for your answer Gojko! The maintenance nightmare is exactly what I'm experiencing right now. When business logic changes, I have to update a lot of scenarios because I'm trying to reuse steps. I know what I have to do right now. Thanks!
To unsubscribe from this group and stop receiving emails from it, send an email to specificationbyexample+unsub...@googlegroups.com.

Chris

unread,
Mar 2, 2019, 3:01:41 AM3/2/19
to specificati...@googlegroups.com
I find it helps to write the GWT backwards. Start with THEN -> WHEN -> GIVEN.

Any given or when from another system/component becomes a then.

To unsubscribe from this group and stop receiving emails from it, send an email to specificationbyex...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages