Segue Steps

Sometimes customer scenarios using Gherkin (Cucumber, SpecFlow etc.) can be harder to read than necessary. Once there’s more than one “And” line in a row, I find that there’s more clutter than I’d like and it doesn’t flow as well when I read it. Let’s take this example scenario of upgrading a fremium service.

Scenario: Upgrade my SomeService subscription from Basic to Pro.
Given I am on the Basic plan
When I upgrade to the Pro plan
Then I see a message confirming the upgrade
And I see that I am now on the Pro plan
And I receive a personal thank you by email
And SomeService keeps a record of when the upgrade happened
And SomeService keeps a record of payment

There’s a feature I rarely see used, the ability to use bullets (with asterisks ‘*’). I’ve found that using this among steps with Given/When/Then can remove some of the clutter, making the scenario easier on the eye…

Scenario: Upgrade my SomeService subscription from Basic to Pro.
Given I am on the Basic plan
When I upgrade to the Pro plan
Then I see a message confirming the upgrade, and:
* I see that I am now on the Pro plan
* I receive a personal thank you by email
* SomeService keeps a record of when the upgrade happened
* SomeService keeps a record of payment

What I don’t like about this, however, is how the ‘Then’ step appears in a different context to the bullets and seems less important. To make sure that all the steps are seen as equally important, I can do this:

Scenario: Upgrade my SomeService subscription from Basic to Pro.
Given I am on the Basic plan
When I upgrade to the Pro plan
Then the following occurs:
* I see a message confirming the upgrade
* I see that I am now on the Pro plan
* I receive a personal thank you by email
* SomeService keeps a record of when the upgrade happened
* SomeService keeps a record of payment

Note how I’ve put in a “Then” step that segues from the “When” to the actual expectations.
A ‘Segue Step’ doesn’t have to do anything, other than transition the reader from the previous steps to a list of expectations:

Then /^the following occurs:$/ do #nothing
#just segue to the next step
end

Another way of using a Segue Step could be like this:

Then I should:
* See a message confirming the upgrade
* See that I am now on the Pro plan
* Receive a personal thank you by email
And SomeService should:
* Keep a record of when the upgrade happened
* Keep a record of payment

Asterisks can replace the opening keyword of any type of step, but using them in this way for Given or When steps could be a scenario-smell, suggesting that the scenario has too much detail or those steps are at the wrong level of abstraction. Using asterisks and Segue Steps are most appropriate in “Then” statements with two or more “And” lines.

After doing this, reading scenarios without asterisks and ‘Segue Steps’ now feels like the “And Then” scene from “Dude, Where’s my Car”…And then? I hope you find it useful to write better scenarios too… And then? And then? And theeeeeeeeeeeeen! And thenandthenandthen!

 

Special thanks to Andy Palmer for reviewing this blog post and helping me say it with fewer words.

  • Nilesh

    Great trick. Thanks for the post

  • Paul Littlebury

    (Very) belated comment, but Gherkin is very flexible. Common misunderstanding is it’s not, but if you look at it as code (which is what it is), it becomes a programming type exercise. It’s just another layer of abstraction (the next layer up from the acceptance test code). Multiple “should”‘s for example, can be treated as an array, in Gherkin. Common steps can be bundled as one Gherkin statement, when specifying complete steps are unnecessary. Forms can be processed as tables, rather than lengthy “I fill in this with that”. Developers appreciate the well-structured scenarios, as it guides them better too. BDD a commitment thing, and so is the Gherkin – it does take time to build up, but you end up with a suite of executable natural language features, and strict QA. It kept a good project momentum going too. The Gherkin art is in keeping it readable, but not letting it stand still. And of course documenting, and alerting others to new Gherkin available to use. The out-the-box Gherkin is a bit mundane, but picks up on many common steps – we are not as original as we think. Where the value becomes apparent, is as the test application grows, and more custom Gherkin(DSL) is created. The value even better demonstrated when integrated with the app it is testing. Becomes it’s own development/testing machine 😉

  • Paul Littlebury

    BDD and the tools were kind of scrappy for a while, but over the last 18 months, the pace, adoption and improvements have been ever-increasing.