You’re Not Doing BDD

The world is full of blog posts about what BDD is, but this is an article about what it is not. BDD is not the right word to use for your integration tests. It is something else entirely.

Let us assume that you, the reader, think you are doing BDD. You may have written some tests for a website or an API. Perhaps you find them helpful, in your day-to-day development. Your team may think that their coverage of the entry surface of your application is an important thing to keep an eye on. You might have developed a fondness for your test runner, be it PHP’s Behat, .Net’s Specflow, or the ever-present Cucumber.

You are not alone. Though lacking hard data, anyone who has interviewed for dev jobs in the last 5 years will understand that many, many job adverts speak of BDD as a required/nice-to-have skill. A small handful of these are telling the truth when they describe Behaviour-Driven Development as part of their process. Many are mistaken.

Signs That You’re Not Doing BDD

Let’s take a look at some things that BDD isn’t. Below is a list of questions. Transport yourself into the mind of a new starter, excitedly cloning your repository for the first time, enjoying the laptop equivalent of new car smell as they do so. Imagine you are looking at your Gherkin language scenarios, and ask yourself these questions:

  1. Is this test for a REST API, a website, or a CLI application?
  2. What database are the fixtures in? SQL, or a NoSQL document storage?
  3. What framework was used to build the application?

If your answers from 1-3 are ‘I don’t know’, it’s possible you might be doing BDD. But if you could at least tell the answer to question 1, you’re not.

What Not Doing BDD Looks Like

Let’s take a look at an example scenario and break this down.

Given the products table contains these fixtures:
| 123 | Sandwich | 2.5 |
When I send a POST request to "/basket/" containing the following json data:
  {
    "product": "123"
    "quantity": 1
  }
Then my basket value should be updated to "£2.50"

This is not a BDD test. It’s an integration test. You can tell it’s an integration test, because you can tell it’s for a REST API. You can also tell what kind of database infrastructure is being used. There’s nothing behavioural about it.

If I’m Not Doing BDD, What Am I Doing?

One excellent thing, one minor mistake, and one thing you should avoid entirely:

  1. Writing good integration tests for your application
  2. Using a behavioural test runner to run your integration tests
  3. Telling people on job specs that your team is using BDD

Point 1 is good news. Integration tests are good, and writing them makes you a good person. Your application will be easier for developers and devops specialists alike to work with in future, and your rewards are in heaven.

Point 2 is not good, but neither is it a big deal. Using a behavioural test runner like Behat won’t kill you. You could have got away with a generic test runner like PHPUnit, and shaved a couple of seconds off your build time. Perhaps reducing the number of dependencies of your project would have been the best choice, but no business ever went broke from using the wrong test runner. Probably.

Point 3 is a bit of a risk. Hiring someone who was excited about all the BDD you said you were doing could backfire. (I’ve been there before, on the candidate’s side of the table. It wasn’t the oft-misused word ‘BDD’ that caused confusion, but a similarly muddled term: ‘Continuous Integration’. But that’s a tale for another article.) To cut a long story short, it is in your best interest to avoid hiring someone who only took the job because they thought you were doing BDD.

But Gherkin Syntax is Helpful!

Gherkin syntax - the Given/When/Then sentence structure - is helpful in a very specific scenario: You are showing your tests to non-technical stakeholders. That’s it. That’s what it’s for. You’re not doing that with tests that have JSON in them.

What Actually Is BDD?

Take a look at the next post in the series - WTF is BDD? - to find out.