What is Behavior Driven Development 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.
