Movatterモバイル変換


[0]ホーム

URL:


Given When Then

21 August 2013

Given-When-Then is a style of representing tests - or as its advocates would say - specifying a system's behavior usingSpecificationByExample. It's an approach developed byDaniel Terhorst-North and Chris Matts as part ofBehavior-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 theFour-Phase Test pattern.

1: In review comments on this, Dan credits Ivan Moore for a significant amount of inspiration in coming up with this.

The essential idea is to break down writing a scenario (or test) into three sections:

Since we're talking about using examples as specifications, it makes sense to show this with an example2

2: fromPete Hodgson

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 Cucumber3, which a popular way of writingBusinessFacingTests 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 tests4. I've also seen this convention to structure informal prose.

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.

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 asFour-Phase Test. His four phases are Setup (Given), Exercise (When), Verify (Then) and Teardown5. Bill Wake came up with the formulation asArrange, Act, Assert.

5: Teardown isn't always needed when implementing tests (particularly if you are usingAutomated 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.

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 usingAutomated 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.


[8]ページ先頭

©2009-2025 Movatter.jp