Last week a few of us got together to go through an excercise in Behaviour Driven Development. The purpose of this was to work through a hypothetical specification together, developing a solution using a BDD approach. There was a very varied level of experience and knowledge of BDD within the group (which was the main reason for doing this) and so we went off on a lot of tangents and discussions about what it was we were trying to do.

One thing that came out of these discussions, which is a perception that I’ve encountered before is that BDD is only useful for ‘acceptance’ style specifications (tests), i.e. that can be presented to, understood and even written by a business user.

What happens when you move into areas of the solution that are not directly concerned with the domain model of the business? Does the business user care or need to understand how your logging infrastructure works, or your custom caching layer, or your IOC container etc. etc.

No, of course they don’t. However, this does not mean that BDD does not apply outside the core business domain model in your solution. Every aspect and advantage of this approach still applies, the difference is that the domain changes. I think the key point about BDD is that it is about language – describing the behaviours of the domain you’re working in using the ubiquitous language of that domain. If the domain changes, then so does the language.

It’s not the business who is the end user of your logging API, it’s your peers in the development team – the dev lead, TAs, another developer etc. These people understand the technical domain, so it’s perfectly valid to use technical terminology in your specifications when developing these areas. So, as you move around through the layers of your solution architecture, the specification langauge will change to describe the behaviors of different parts of the solution.

A great example of this is the SpecUnit BDD framework, used for writing BDD style specifications. The specifications (unit tests) for this framework are written in a BDD style and the full specification is available at http://code.google.com/p/specunit-net/downloads/list. As the users of this framework are technical users, the domain language is a technical too. Here’s an extract from this specification report:

Context specifications    7 contexts, 13 specifications

Context, when a test fixture class is a concern    3 specifications
  • should be attributed with the ConcernAttribute
  • should have a name that is prefixed with the concern name
  • should have a concern name that is the name specified by the concern attribute
Context, when a test fixture class is not a concern    3 specifications
  • should not be attributed with the ConcernAttribute
  • should not have a name that is prefixed with the concern name
  • should not have a concern name
Context, when building a context for a test fixture type    2 specifications
  • should collect and build the specifications
  • should create a specification for each test method in the type
Context, when creating a context for a type that is not a test fixture    1 specification
  • should cause an error
Context, when two contexts represent the same test fixture    1 specification
  • they should be equal
Context, when a context behaves like another context    1 specification
  • should have a subclass whose name begins with “behaves like”
Context, when a context does not behave like another context    2 specifications
  • should not have a subclass whose name begins with “behaves like”
  • may not have a subclass

To a developer this makes sense. If you wanted to use this framework, or maybe contribute to it by adding a feature, this specification uses the right language for you in order for you to understand it. It might not seem that this specification is written in the ubiquitous language of the business, but it is – in this case the business is that of software development and, more specifically, in domain of automated software testing. You may have your own custom testing API within your solution with a whole load of specifications for it describing its behaviour. Not for the benefit of the business, but the other users of that API.

I would argue that BDD is not just for ‘acceptance’ testing, but can be used at all layers of an application. A full specification across an entire solution might incorporate multiple domains – those of the business and those of a technical nature. The business users will be concerned with the specifications that involve their domain.  This is one of the main selling points of BDD – that the business and development team and talking the same language. I would go one step further and say that its just as valid that the development team are talking the same language amongst themselves – I know that I would love to have full, clear, easy to understand executable specifications for all the APIs that I use as a developer, as is the case with SpecUnit – it would definitely make my job a lot easier!