Personally I favour the phrase “Specification by Example” over the more commonly used term “Behaviour Driven Development” (BDD). That is because I demand the specifications are by example but only encourage my developers to do outside-in test first development (from BDD).

Behaviour Driven Development (BDD)

In the last couple of years there has been a step change in automated testing. Automated testing is now more pervasive – I expect teams to be doing some kind of automated testing – but more significantly the focus is moving from unit tests (almost a given) to more user focussed tests. If we have to write down requirements, and most teams need to, then we may as well write the requirements so the requirements can also be automated tests.

Getting executable requirements demands a process change and there is a pretty good offering from Behaviour Driven Development (BDD). BDD borrows the test first aspect of Test Driven Development (TDD). A developer must:

1. write a test or tests
2. write the code to meet the test
3. run the test to verify the code works
4. repeat until done

BDD also promotes outside-in TDD. In other words do TDD for functional/acceptance tests first then write unit tests as part of coding. In test first outside-in development the developers:

1. write a acceptance test or tests for the behaviour of interest
2. write the code to meet the acceptance test
   1. write a unit test or tests
   2. write the code to meet the unit test
   3. run the unit tests to verify the code works
   4. repeat until done
3. run the acceptance test to verify the code works
4. repeat until done

I love that process, I just don’t like the BDD tag. It is all in the name. I’m a huge fan of User Stories that define behaviour and BDD follows that model by demanding the tests are written in terms of the desired behaviour. Seems fair enough but it is exactly the emphasis on behaviour that I object to.

The trouble with BDD is that people see the word “behaviour” and start generating automated test scripts to drive the user interface to fulfil the user story. I think that is a mistake. It leads to brittle tests.

If you drop the label “behaviour” then we’re left with the solid but un-attractively named process: outside-in test-first development.

Specification by Example

Gojko Adzic coined the term Specification by Example and it is the title of his book (Adzic, 2011). He choose this name over competitors, such as Behaviour Driven Development (BDD), as the phrase put the focus on the nature of the requirements, “examples”, rather than other things such as the development process or the user interface.

Rachel Davies, in her post BDD in a Nutshell, neatly shows how the requirements aspect of the process works. Specification by example involves conversations. In an Agile team the product owner (PO) discusses the requirements with the team – business analyst (BA), tester (QA), developer (SE) before and during development. Specification by Example just encourages this and formalises it. And delivers very specific examples.

BDD in a Nutshell (Rachel Davies)

Specification by Example abandons the older style of describing requirements with abstract statements in favour of concrete examples. Hence the name of course. “Concrete” is my term but means the tests are precise, complete, and realistic.

Although some people view Behaviour Driven Development and Specification by Example as synonymous they aren’t really. BDD puts the emphasis on behaviour and is often used to mean the technical testing process. Specification by Example puts the emphasis on the outcome of a requirements process. To repeat what I said at the start of this post, I demand the specifications are by example (outcome from requirements process) and I encourage my developers to do outside-in test first development (technical process). My user stories are usually behavioural but I squirm uncomfortably if the tests are.

In a future post in this series I’ll describe the guidelines I’ve given my team on how to write Specifications by Example.

References

Adzic, G. (2011). Specification by Example: How successful teams deliver the right software. Manning.

Davies, R. (2012). BDD in a Nutshell. Agile Coach.