Contemplating Given-When-Then

This week, Chris Matts tweeted, “Contemplating whether GIVEN-WHEN-THEN is back to front. The system should do <outcome> WHEN <event> PROVIDED <stimulus context>… Hmmm.” Let’s try an example. “Given I have $500 in my account, when I withdraw $50 then I have $450 in my account” becomes “The system should show $450 in my account when I withdraw $50 provided I had $500 in my account before.” It doesn’t exactly roll off the tongue, does it? Putting the result first makes the sentence both more complex and more passive. Yet I can understand the impulse that triggered this tweet.

Given-When-Then describes the scenario in chronological order, which also makes it easier to automate. Often I don’t implement it in that order, though. Instead, I’ll flesh out the Then with code fixtures first, as the results are the primary focus. The When is usually a straightforward single interaction with the system. The Given describes the business pre-requisites, and these get translated into actions that make the When interaction work. Starting with the Given can lead us astray into specifying things that don’t need to be specified for this scenario.

Sometimes we discover that there are other pre-requisites, too. These may be things that are simply taken for granted or implied by the specified context of the test. We take for granted that the system is up and running. Having money in the account implies that the account has been opened. We also assume that there are no special cases in the context that would invalidate this scenario. The account having a hold put on the account by the fraud department is not a reasonable assumption. This is a case that needs checking, but in another scenario where the special context is explicitly mentioned.

If there are other things that need to be initialized for this test that are not mentioned in the Given setup, then it’s time to pause to reflect. Could this indicate a mismatch between the world envisioned by the business and the implementation in the system? That could be something to correct. Or might it be something that is often implicit in business conversation, but needs to be explicit in the test. Maybe the type of account affects whether or not a fee is applied to withdrawals. Sometimes the business gets into the habit of speaking in shorthand that leaves out some important distinctions.

I’m still happy with “Given <this context>, when <an interaction occurs> then <a result>” as a formula for acceptance tests or executable requirements. I don’t know that this is the only good formulation. I’m still looking for others that would naturally occur to business people, and would love to hear some examples if you have them. While I don’t think Do-When-Provided is natural business-speak (I could be wrong in some businesses), it’s good to consider alternatives.

Given-When-Then is a formula. While it can help stimulate our thoughts, it shouldn’t limit them.

In the same manner, Mike Cohn’s canonical expression of a User Story, “As a <type of user>, I want <some goal> so that <some reason>,” helps us to remember to think about which user and why they’re requesting this. I generally counsel teams not to actually write their stories in this way, as it often results in a wordy and repetitious list that obscures the essence of the story instead of highlighting it. There’s nothing like a long list of “As a customer, I want <to do something> so that I can make a purchase.” The formula can lull you to sleep. I’ve seen examples of this were “making a purchase” was not really what the customer wanted, it was the way what the customer wanted was implemented. And I’ve seen “As a user…” fill in for customer, obscuring the fact that not all users of the system are customers, and not all stakeholders who want something from the system are users.

These formulae are thinking tools. Use them in ways that provoke thinking. If they’re just chores to be done or checkboxes to be checked, they’re not helping.

Post to Twitter Post to Plurk Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to MySpace Post to Post to Reddit Post to StumbleUpon

Comments (8) to “Contemplating Given-When-Then”

  1. Kent Beck gave this advice in the TDD book … he said to start the test at the assertion n’ work your way up to the setup … i <3 doing that, eventhough intellisense helps more following the logical path

  2. “$450 is the resulting account balance when $50 is withdrawn from an account balance of $500.”

    I find that at least as pleasant as the one in G-W-T form, but perhaps it’s because I’ve spent years orienting my programming along that pattern.

  3. A point that often gets lost is that the “As a…” formula came from Connextra. It was a temporary fix when they felt that their story breakdown was becoming unfocussed. Later, when they had recovered, they dropped the formula and just went back to headlines.

  4. George

    Great post. It captures and expands on my thinking perfectly.

    As Agile moves away from the motivated it gets adopted by the “less motivated” who may just follow it by rote. That is why I’m reconsidering whether the G-W-T needs revisiting.


  5. This is similar to how many programming languages, especially scripting languages from the past couple decades, allow you to put an “if” or “unless” clause at the *end* of a line instead of the start. IOW, it used to be always “if this then do that”, but now they also allow “do this if that” (or less commonly, “do this unless that”).

    In both cases, sometimes it is indeed a more natural fit. Especially, “barf if there’s an error”. But sometimes, not so much. Different tools for different jobs….

  6. Thanks, Chris. I’d suggest “augmenting” rather than “revisiting.” As Dave points out, different expressions fit better in different situations. I think we need to identify some other role models to express what we want to have happen.

    Having a handful of models still gives people a useful framework for hanging their thoughts, but forces a choice which counteracts the “by rote” tendency.

  7. […] Contemplating Given-When-Then I took this to […]

  8. Start with the assertion, so that the test specifies the minimum necessary to compute the value in question. This leads to smaller tests. This leads to less cost.

    Start with the assertion, so that the example (business test) specifies the minimum necessary to compute the value in question. This leads to smaller tests. This challenges our assumptions about the scenarios. This surfaces unspoken assumptions that we might have wrong, and now we can deal with that.

    Start with the assertion, …, so that when we realise that we can get away with building only 30% of what we expected to need to build, we find it harder to argue against that realisation.

    This last one makes lean product design work.

Post a Comment
*Required (Never published)