BDD Part 1 of N

Lets talk about software development. Recently I have worked to get a team I am part of using a new development methodology called BDD, or behavior driven development. If you develop software at all, and have not been living under a rock for the past 10 years you maybe wonder if BDD is anything like TDD.

The answer is a little, but with some key differences. First and for most unit testing is about function/method level validation. Secondly it is an internal development practice (your stakeholders *should* not care if you do TDD). BDD is about a higher level of validation. It is about verifying the application works. It is also something your stakeholders should care about.

When do you develop software using BDD before you ever write a line of code you must write what is called a scenario. A scenario is nothing more specification or requirement defined by example.  There are a near infinite number of ways one could go about doing this, but I am a strong advocate of using something called Gherkins. Gherkins is nothing more than a grammar for documenting the preconditions, key actions, and expected outcomes.  [This will be covered in a later article.]

After the scenario(s) are documented development can start. As these scenarios are really the solidified requirements for the application it is fitting that they also become the acceptance tests which the application will need to pass.  The first problem which needs to be solved is how to turn scenarios into an executable set of tests.  Each scenario is made up of steps. These steps are converted into executable code which can drive the application (through the real ui). As the driver is being developed the code make the steps succeed is written.

Once a feature is implemented, you should have an automated set of acceptance tests that prove the applications works. Which frees your testers, and quality assurance engineers up to worry about how the application works and not if it works.

What maybe surprising to you though is the automated acceptance tests are not even the biggest value of BDD. The biggest value of BDD is the scenarios give developers, stakeholders, and business analysts a framework for communicating about what will and will not be implemented.