This post originated from an RSS feed registered with Agile Buzz
by Martin Fowler.
Original Post: Bliki: GivenWhenThen
Feed Title: Martin Fowler's Bliki
Feed URL: http://martinfowler.com/feed.atom
Feed Description: A cross between a blog and wiki of my partly-formed ideas on software development
Given-When-Then is a style of representing tests - or as its
advocates would say - specifying a system's behavior using SpecificationByExample. It's an
approach developed by Dan North and Chris Matts as part of
Behavior-Driven
Development (BDD). [1] It appears as a structuring approach
for many testing frameworks such as Cucumber. You can also look at
it as a reformulation of the Four-Phase
Test pattern.
The essential idea is to break down writing a scenario (or test) into three
sections:
The given part describes the state of the world before
you begin the behavior you're specifying in this scenario. You can
think of it as the pre-conditions to the test.
The when section is that behavior that you're
specifying.
Finally the then section describes the changes you
expect due to the specified behavior.
Since we're talking about using examples as specifications, it
makes sense to show this with an
example [2]
Feature: User trades stocks
Scenario: User requests a sell before close of trading
Given I have 100 shares of MSFT stock
And I have 150 shares of APPL stock
And the time is before close of trading
When I ask to sell 20 shares of MSFT stock
Then I should have 80 shares of MSFT stock
And I should have 150 shares of APPL stock
And a sell order for 20 shares of MSFT stock should have been executed
The above example uses Cucumber [3], which a popular way of writing
BusinessFacingTests but you can use the Given-When-Then
style with any kind of tests. Some people like to put
Given-When-Then as comments to mark informal blocks inside unit
tests [4]. I've also seen this convention
to structure informal prose.
It's usual with this approach to see "ands" used to combine
multiple expressions within each clause.
I've characterized the given as a description of the
pre-condition state because that's the way I prefer to think of it.
A testing framework, however, interprets the givens as a set of
commands to bring the system-under-test into the correct state before
executing the when command. (Which is why other naming conventions
often call this "setup".) Testing frameworks provide various query
methods for the then commands - these should
be free of side-effects.
Although Given-When-Then style is symptomatic to BDD, the basic
idea is pretty common when writing tests or specification by
example. Meszaros describes the pattern as Four-Phase
Test. His four phases are Setup (Given), Exercise (When), Verify
(Then) and Teardown [5]. Bill Wake came up
with the formulation as Arrange, Act, Assert.
Notes
1:
In review comments on this, Dan credits Ivan Moore for a
significant amount of inspiration in coming up with this.
3:
Or to be strict it uses Gherkin, which is the name of Cucumber's
DSL.
4:
Test frameworks tend to follow either
naming style of xunit or BDD, the latter tend to name methods in the
Given-When-Then style.
5:
Teardown isn't always needed when implementing
tests (particularly if you are using Automated
Teardown) and doesn't add much to the communication aspect of
specification by example. So it's reasonable to see it missing from
the BDD style.