Agile software delivery encourages a focus on quality; working software is more important than comprehensive documentation. [1] One of the key changes in the past 20 years has been the approach to testing software. The basis of these techniques can be borrowed in other domains.
TDD, or Test-Driven Development, refers to a style of programming in which three activities are tightly interwoven: coding, testing and design. [2] It can be succinctly described by the following set of rules:
This approach seeks to ensure quality by emphasising and requiring testing to drive the development process.
BDD, or Behaviour-Driven Development is a synthesis and refinement of TDD and Acceptance Test Driven Development (ATDD). [3] BDD focuses on the expected behaviour to a change in a system.
The “Given, When, Then” notation is often used to document intended behaviour. It is a style of representing test cases specifying a system’s behaviour using examples for system specification. [4]
Example:
Given I have 100 shares of Microsoft stock
And the time is before the close of trading
When I ask to sell 20 shares of Microsoft
Then I should have 80 shares of Microsoft
And a sell order for 20 shares of Microsoft stock should have been executed
Some of the benefits of using this approach:
When dealing with software development, many programming tools such as Cucumber and JBehave provide test features that accommodate tests defined in the Given-When-Then format. Though this is the case, the approach to testing business requirements is not limited to software products.
1. Manifesto for Agile Software Development. https://agilemanifesto.org
2. TDD. https://www.agilealliance.org/glossary/tdd/
3. Behaviour Driven Development (BDD). https://www.agilealliance.org/glossary/bdd/
4. Fowler, M. (2013) Given When Then. https://martinfowler.com/bliki/GivenWhenThen.html
All fields are required.