This article is part of a series on Tests in general and on how to practice them:
- Tools overview
- Test Driven Development
- TDD: just do it!
- spec BDD
- phpspec: a quick tour
- Behavior Driven Development: story BDD
- Behat: a quick tour
In this article, we'll talk about Behavior Driven Development (BDD), again. There's no special skills required to read on, although some notions on tests and Test Driven Development (TDD) would be a plus.
From spec BDD to story BDD
So TDD has 3 simple rules:
- write the test first
- then write as quickly as possible the code to make it pass
- finally refactor, without changing the tests (and still making them pass)
Like many TDD oficionados, Dan North felt that it was missing some guidelines. To fix this, he created spec BDD, which adds the following rules to TDD:
- test methods should be sentences (prefix them with
- tests should specify the behavior of the System Under Test (SUT)
One of his colleagues, Chris Matts, suggested to take BDD a step further: why not making sure the business value was met? And that's how story BDD was created.
If you're working with agile methodologies, you should be familiar with user stories. Those are simple cards which describe what to do in 3 lines:
In order to attain a business value As an actor I need to meet some requirements
They've also some acceptance criteria, which follow approximately this template:
Given a context When an event happens Then an outcome should occur
If the system fulfills the acceptance test, then it behaves correctly. By making them executable, you can test the business behavior of your system! That's what story BDD is all about.
Technically, this means parsing the acceptance tests and match each line with a chunk of code. But don't worry about implementation details, we'll see them in the next article.
Somehow, a surprising number of people started to think that BDD was all about integration tests. For example in a web application, they would write:
Given I am on "/home" When I click on "form#name_form input[name=submit]" And I wait until the page is fully loaded Then the "form#name_form input[name=first_name]" form field should contain "value"
What's wrong with it? Well:
- it's not human friendly (usage of xpath)
- it's completely coupled to your routing (usage of URL)
- it's entirely coupled to the web implementation (usage of web vocabulary)
- it's thoroughly coupled to the HTML integration (again, usage of xpath)
- it's fully coupled to the test tool (the waiting line is a hack)
- and mostly: it doesn't describe your business need
Here's a better approach:
Given the opportunity to introduce myself When I give my name Then I should be greeted
Yep, that's the story BDD example of "Hello World", in case you didn't recognize it ;) .
If you make a user story's acceptance tests executable, then you're doing story BDD. It helps you to make sure that your application meets your business needs.
Hopefully this article helped you a little. If you have any questions, rants or praises, feel free to send them to me on Twitter.
Tests are hard. TDD is harder. BDD even more! Here's some good references to help you on story BDD: