Workflow testing using GIVEN WHEN THEN

[Kirill Kamaldinow]

I сomplemented previously my user stories with additional scenarios if user story covered a complicated workflow and was using acceptance criteria written in a form of bullet points.

Then I decided to switch to acceptance tests using GIVEN WHEN THEN. However, I'm struggling to write scenarios for worflows in this case. 

Let's take such an example: there is a music recording flow where user is able to add up to 5 tracks(his recorded vocals) to the initial song.

And I need to test the following scenario User adds new track to the song which have already 1 existing track

GIVEN song was uploaded to the studio; AND song has already 1 track added; AND song is being played currently (current playback point is synchronized with record start point); WHEN user starts recording his voice; AND sings on a song; AND stops record when he is done or when end of the song is reached; THEN user’s voice was saved as a new track; AND previous track wasn't affected; AND recorded track starts playing automatically from record start point; AND user sees control for adjusting volume of new(last) track.

As you can see there are a lot of points relating to workflow. Could you, please, share your thoughts how use scenarios in GIVEN WHEN THEN form relating to complex flow? Should I split flow for single steps and to provide scenario for each step of the flow?

I look forward to hearing your advices!

[Gojko Adzic]

Hi,

I like to put all the preconditions into the Given block, and have a clear focus on a single thing under test in the When section. The Then section should contain all the post-conditions. 

With flows, there are usually several aspects described by scenarios (the sequence of steps in a flow, how things are connected/passing the data correctly between the various steps, and the business logic of particular steps). I prefer to keep each of those in a separate spec (or even a set of specs), so you can describe things on different levels. 

for example, showing the path coverage/sequence of steps, you might describe several key paths throughout the whole flow. in this case, the selection criteria for that particular path would go into the given block, the objective/exit criteria for the path would go into the When block, and the steps would go into the then block. something like this:

Given Mike is an existing user with a valid account

and Mike has recorded 1 track for the "Never Gonna Let You Go" song

and the  "Never Gonna Let You Go" song is currently playing

When Mike wants to add a track to the  "Never Gonna Let You Go"  # <- 

Then Mike would have to <step 1>

and Mike would have to <step 2>

and Mike would have to <step 3>

10-15 such scenarios gives you critical path coverage for the overall flow, then you can focus more detailed scenarios on individual cases, eg what happens if the song is interrupted half-way through etc.

gojko

--
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 specificationbyexample+unsub...@googlegroups.com.
To post to this group, send email to specificationbyexample@googlegroups.com.
Visit this group at https://groups.google.com/group/specificationbyexample.
For more options, visit https://groups.google.com/d/optout.

[John Lockhart]

Wow interesting to see Gojko's response. I'd never considered a "would have to" pattern - will have to bear that in mind. 

Also impressed to see him sticking to the explicit examples approach - I tend to be slack regarding that as you'll see from my example below.

My attempt at a flow like you describe would (and not claiming it's good) probably look like:

GIVEN song with one track is playing

AND user is recording his voice;

WHEN user stops recording

THEN user’s voice is saved as a new track AND previous track is not affected AND newly recorded track is playing from record start point AND user can adjust volume of newly recorded track

If the "when end of the song is reached" is a meaningful different example it would be a separate scenario but not clear from what you've said whether that stops recording automatically - presume it does, in which case would be.

GIVEN song with one track is playing

AND user is recording his voice;

WHEN song reaches end

THEN user’s voice up to the end of the track is saved as a new track

AND previous track isn't affected AND newly recorded track is playing from record start point AND user can adjust volume of newly recorded track

How does that sound?

BTW I'm not sure "previous track is not affected" is really relevant or justified (is it a risk or something someone might wrongly assume should happen?). Shorter and simpler is better in general I think.

cheers,

John