Test Driven Development is the process of using examples to guide the development of each function of your software. In TDD you create your program by working through a loop like this:
- Write an example as a simple test
- Watch the test fail
- Write code to make the test pass
- Refactor and clean your code
So what is Behavior Driven Development? BDD is somewhat similar and complementary to TDD. However, where TDD focuses on driving the development of the individual functions in the code, Behavior Driven Development applies a similar process at the level of features.
Since features are driven by user needs and most users are going to express themselves in natural language rather than the language of code, BDD starts with a natural language to create examples. To make the examples executable BDD requires a little bit of structure and this structure allows a bridge between the world of programming and the world of natural language requirements.
A BDD feature file consists of one or more scenarios. These scenarios are just examples of how the application should behave from the standpoint of a user. For example you might have a scenario that says:
Given I am on the login page
When I attempt to login with valid credentials
Then I am shown the application dashboard
And another scenario that says:
Given I am on the login page
When I attempt to login with invalid credentials
Then I am shown a login error message
These examples are written in English, but are still very structured. The Given portion tells the starting condition for the example, the When line tells what you actually do, and the Then tells what results are expected.
Behind the scenes, your BDD framework will match this natural language to code that developers write to actually do those steps, but it is always driven from the natural language.
The feature files then become the documentation of the application, but unlike most documentation they get executed against your program. If this documentation ever gets out of date, then something will break in your testing stage. Any change made to the software gets verified by every example that was created in this process of documenting the requirements as an executable specification.
None of this is magic. It is a lot of hard work and requires a lot of discipline across the development team, but the results can be amazing. Not only does BDD streamline the requirements process, but it brings the value of QA to the beginning of development.
One BDD project I coached involved a complete replacement of a very important legacy mainframe system. The system went live a year early and at 1/3rd the cost of what had been estimated using their traditional development method. The ability to execute every requirement against the application let the team regularly deploy new changes in days that normally would have taken 6 months.
The business owners identified a small change that would let the application make more money. The change was made in a few hours, but under the old process it would have taken 6 months to make sure there were no side effects and that it was safe to deploy. Because of the investment in BDD, the change was put into production almost immediately, fully tested and with complete confidence. BDD cut out 6 months where that change would not have been producing any value. For this single change, BDD resulted in savings of $5 million that would have been simply lost under their old process.
