Whereas TDD focused on making sure that code worked and caught exceptions gracefully, BDD focuses on making sure that the functionality delivers business value and satisfaction to users.
A typical BDD process might look like this:
In behaviour-driven development:
- User behaviour drives development
- The team elicits user stories
- An analyst creates feature files
- The feature file becomes the test harness for development
- The team develops and tests against feature files
The key features of BDD are:
- we write behaviour & specification that then drives our software development.
- features are based on actual user behaviour & scenarios & user stories.
- the tests can be written by business analysts and stakeholders.
- Developers deliver what the users actually want
- It is rigorously tested
- The test shows that the feature meets the requirements (as opposed to merely proving that it works)
Further reading
- Behavior-driven development (Wikipedia)
- Dan North's article introducing BDD
- Getting Started with Behavior Driven Development (BDD) - Part 1
- Say Hello To Behavior Driven Development (BDD) - Part 1
- Say Hello To Behavior Driven Development (BDD) - Part 2
- Behavior Driven Development Using Ruby (Part 1)
- Behavior-Driven Development Using Ruby (Part 2)
- In pursuit of code quality: Adventures in behavior-driven development by Andrew Glover
- The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends
- ScalaTest: Tests as specifications
- Unit test JavaScript applications with Jasmine (including behavior-driven development)
- Chai BDD/TDD Javascript Library Assertion Styles
- Choosing a BDD framework for .NET
- Using Keywords to Support Behavior Driven Development by Hans Buwalda
- TDD vs. BDD
No comments:
Post a Comment