Test-driven development (TDD) is a software development process originated from Extreme Programming (XP) invented by Kent Beck, which relies on the repetition of a number of short and continuous development cycles.
TDD can lead to more modularized, flexible, and extensible code; the early and frequent nature of the testing helps to catch defects early in the development cycle, preventing them from becoming endemic and expensive problems. In addition to this, its principle completely practices “keep it simple, stupid” (KISS) and “You ain’t gonna need it” (YAGNI). The workflow for TDD is as follows:
BDD is based on TDD; it inherits all the benefits and many of the principles/practices from TDD, but moves one step forward—BDD combines TDD with ideas from domain-driven design (DDD) and object-oriented analysis and design which provide software development teams and business people with shared tools and a shared process to collaborate on software development. The inventor of BDD, Dan North, defined it as follows:
“BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.”
BDD focuses on implementing the minimum marketable feature (MMF) that will yield the most value. The business team and the development team can cooperate on a common language; this significantly reduces misunderstanding and eliminates waste, unnecessary code, and functionality.
In the BDD style, when a developer starts writing a test case, unlike writing a test method in TDD, he/she writes a “feature” belonging to a “story” which describes the feature’s expected behavior. The feature is a business-readable, domain-specific language. Then the developer runs and watches it fail; after that he/she implements the “feature” and makes the test pass just like the same process in TDD. So at its core, BDD is a specialized version of TDD that focuses on the behavioral specification of software units.
How to do it…
The typical process can be described in the following steps:
Add a feature test.
Run all tests and see if the new one fails.
Write some code.
Run the automated tests and see them succeed.
Refactorize the code.
Repeat steps 1 to 5.
There are many great resources online for learning BDD:
Official page of behavior-driven development: http://behavior-driven.org/
The behavior-driven development entry on Wikipedia: http://en.wikipedia.org/wiki/Behavior-driven_development
10 Reasons Why BDD Changes Everything: http://www.agile-doctor.com/2012/03/06/10-reasons-why-bdd-changes-everything/
Behavior Driven Development Content on InfoQ: http://www.infoq.com/BDD
Introducing BDD: http://dannorth.net/introducing-bdd/
Instant Cucumber BDD How-to
By: Wayne Ye;
Publisher: Packt Publishing