BDD is a software engineering process based on Test-driven Development (TDD). Martin Fowler explains TDD on the following URL:
http://martinfowler.com/bliki/TestDrivenDevelopment.html
BDD combines the best practices of TDD, Domain-driven Development (DDD), and Object Oriented Programming (OOPs). You can learn about DDD on the following URL:
http://martinfowler.com/tags/domain%20driven%20design.html
In an agile team, scoping a feature is a mammoth task; the business stakeholders talk about business interests and the development team talks about technical challenges. BDD provides a universal language that allows useful communication and feedback between the stakeholders.
Agile methodologies include Scrum, Lean, Kanban, XP, and so on. Agile methodologies believe in self-organized teams. You can get more information about agile development on the following URL:
http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/
Dan North developed BDD and created the JBehave framework for BDD. He defines BDD as follows:
"Behavior-driven Development is about implementing an application by describing it from the point of view of its stakeholders."
He proposed the following best practices:
- Unit test names should start with the word should and should be written in order of business value.
- Acceptance tests are different from unit tests; unit tests are written by the developers whereas acceptance tests are written by analysts and other stakeholders. Acceptance testing is carried out to assess the system's acceptance against the business rules. Acceptance tests (AT) should be written in a user story manner, for example, As a [role] I want [feature] so that [benefit]. You can get more information about acceptance tests at the following URL:
- Acceptance criteria should be written in terms of scenarios and implemented in the following manner:
Given [initial context], when [event occurs], then [ensure some outcomes]
A user story describes a testable requirement, and a scenario defines the completeness or acceptance criteria of a story.
Let us write a user story for our stock broker simulation:
- Story: A stock is sold in order to maximize the profit. As a stock broker, I want to sell a stock when the price goes up by 10 percent.
The following is a scenario example:
- Scenario: 10 percent increase in stock price should sell the stock to the market. Given a customer previously bought 'FB' stocks at $10.00/per share and he currently has 10 shares left in his portfolio when the 'FB' stock price becomes $11.00, then I should sell all the 'FB' stocks and the portfolio should have zero 'FB' stocks.
Mockito supports the BDD style of writing tests, using the given-when-then syntax.