Did you really get Behaviour Driven Development?

You maybe have noticed some new articles and product announcements recently, that turn themself in the ‘tradition’ of Behaviour Driven Development (BDD).
Most of them mainly concentrate on the introduction of a new vocabulary in order to get rid of the test centric terminology. Some of them even suggest to stick with the well known xUnit test frameworks and mainly kind of change their test method names (if only they contain the now famous word ‘should’) and think they’re done … really?

Language is not THE Key

Well, of course BDD is also about using the right Language (according to the linguistic theory of Sapir-Whorf), but this is only ‘one’ legitimate instrument leveraging BDD, not the final goal! Furthermore, you won’t do BDD only by changing your vocabulary and continue to test the correctness of your traditional units (like classes or methods), only using another weapon.

So even you’ll use no test centric terms any longer, as long as you still use any kind of Language in order to verify that your code works appropriate (in the sense of ‘i got some piece of code here and now have to find out if it works properly‘), we do not talk about BDD!

Documentation is not THE Goal

Yes, BDD emphasizes the value of comprehensible documentation. And yes, having an appropriate Language that makes it easy to produce readable ‘verifications’ is of great value (at least if you want to learn something about the code that get’s verified or in case a verification fails and you have to identify the cause respectively the intended behaviour of the code)!

But that’s only a side effect, since it can also be achived with ‘ordinary’ unit tests that act as so called documentation tests!So under the view of achieving communicating verifications, BDD doesn’t really differ from the usual way of TDD. It’s considered important for supporting the main Goal, but it isn’t THE Goal of BDD.

Still testing units ?

Most of those new tools still stick to the idea to center their ‘verifications’ around the traditional units, like classes or methods. That said, the structure of your verification code mostly reflects the technical structure of your production code (this will often result in very brittle tests, where your verification implementation is tightly coupled to the implementation of the code being verified. This fact will increasingly set a constraint on refactoring code rather than enabling it, because it requires altering the tightly coupled verification logic as well and so becomes both time-consuming and error-prone).

In effect, instead of looking at a piece of behaviour under a certain context (no matter if this is achieved by a single class or a group of collaborators) you still look at a certain method and verify that it behaves correctly under a range of conditions. So the focus is still mainly on methods on single classes instead of pieces of behaviour.

Still testing state ?

If you are looking at a single unit (e.g. looking at a single class) you are really tempted to mainly make assertions about the state of that unit (for example before and after a method was called), mainly that’s because it’s more or less the only area you can make assertions about when looking at a single class. While a class may be a valid building block for some behaviour you’re interested in, it might prevents you from looking at behaviour that’s only achieved by a set of collaborators.

In addition to that, since you’re mainly focussed to some state of a single unit, you won’t be looking about the collaboration between multiple ‘units’. So the behaviour, that manifests in the interaction between those units is mostly disregarded.

No emphasis on Interactions

As said, some tools don’t regard most of the behaviour by not looking at interactions. In BDD, Mock objects are considered as an appropriate way to look at interactions, so a tool in the sense of BDD should offer a smooth inegration of a mocking framework or at least provide some mechanics to express expected behaviour in form of interactions. Having the focus on interactions i could really start looking at behaviour in the sense of what a building block does instead of how it does some functionality (like with state based testing).

It’s NOT about verification

Granted, using a test centric Language might head to some misconceptions and mistakes because we might think it’s about testing. Admitted, the current TDD vocabulary shapes a mindset that might takes us in a (wrong) direction, but as mentioned above, Language alone is not the Key to BDD, as long as you still think about verifying the state of single units at the core in a comprehensible way.

Not thinking about testing is a major statement of BDD: TDD is not a verification method but a design process – and BDD tries to highlight this fact, not by introducing a completely new method but by readjusting the focus – away from making assertions (proofing the correctnes of our code) towards expressing expectations about the behaviour of our code!

It’s about Specification

So if you write down expectations of what your code will have to do, your mindset will (hopefully) change slightly: You no longer write (unit) tests, but specifications of expected behaviour.
So what’s the difference you may ask. Verification (aka testing) is all about making sure (i.e. proofing)
that your code functions correctly while a specification is all about defining what it means for your code to function correctly’ (Uncle Bob)!

So what we need is in fact a specification framework (instead of a test framework) that may provide a specification oriented language. But that’s not enough. As long as we stick to some ideas (like units or looking at state instead of interactions aka behaviour) that easily lead to proofing code instead of looking at expected behaviour, we won’t do TDD in the sense of BDD.

Far more important than any framework is the change of your mindset! It’s about a design process centered around readable (and as a side effect executable) specifications that will drive the design of your system. And any Article or tool that will guide you in this direction is of great help and truely in the tradition of BDD.

So think about Specification, not Verification – that’s what it’s all about.