Behavior Driven Development what?

Like many, I was fuzzy on BDD or Behavior Driven Development until I started working with BDD tools like Cucumber, JBehave, and Jasmine. However, BDD isn’t a tool. It’s a design approach you can use with your existing testing tools or by adding in additional tools.

BDD refers to one way of doing TDD or Test Driven Development. Specifically it’s outside-in TDD. You start on the outside, writing an automated acceptance test that describes the expected UI functionality. For example, your test might open a login window, fill in and submit the login form and then verify that you are indeed logged in as a result. Here’s what that looks like in a tool like Cucumber:

This is the behavior part. You’re starting with an executable test of how your application behaves as the user interacts with it. The test also serves as easily readable documentation of the expected behavior, which helps ensure product, software, and QA teams are all on the same page.

At this point, the test should fail because you don’t have any login functionality implemented.

Now go down a level and write unit or integration tests for the controller and start filling in the controller logic. The controller test will fail because you need model layer functionality. Go down deeper and write model layer tests and functionality until the model tests pass. Come back out a layer and get the controller tests to pass, then come out another layer and get the acceptance test to pass so all tests are green. Do a little refactoring while keeping the tests green until you’re happy with the code. Hand it over to the product owner for review.

And there you have BDD. The expected behavior of the application from the user’s perspective drives your development as you work from the outside in. You write lower level code in response to needs from a higher level of the system (where the highest level is your UI). It takes a lot of practice but it’s an extremely rewarding and efficient form of development! Compare that with more typical inside-out development where you start developing at the lowest layer (model) and then build up to the UI only to find that what you thought you needed in the controller and UI layer won’t do.