Cucumber is a very fun and cool tool for writing automated acceptance tests to support software development in the behavior-driven development (BDD) style. This Instant book will cover the basis of TDD/BDD and explain the essence of Cucumber, describe how to write Cucumber features to drive development in a real project, and also describe many pro tips for writing good Cucumber features and steps. We will finally introduce some famous third-party libraries used in line with Cucumber.
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.
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/