Last week several of my colleagues and I watched a Google Tech Talk on Beyond Test Driven Development: Behaviour Driven Development, presented by Dave Astels way back in March 2006.Although four years can seem like an eternity within software development, I found this video extremely pertinent to what I find myself doing today. I have been following the principles of Test Driven Development (TDD) for many years now, however this is the first time I have really delved into Behaviour Driven Development (BDD). I would thoroughly recommend watching the video if you have 45 minutes to spare, however, if not, I have summarised the notes I took whilst watching it below.
My Notes
BDD is an evolution of TDD. Dave Astels described it as what TDD looks like if it is done well.
When talking about unit tests, what is a unit? Is it a method? Is it a class? The definition of unit is ambiguous.
BDD is attempting to move away from several of the words that Dave Astels believes have negative connotations after their use within TDD:
- Instead of calling something a test it’s called a specification or spec for short.
- Instead of using assertions we should use expectations instead. Anyone using mock objects will already be familiar with this concept.
One of the key things to avoid is state based testing. Depending on the internal state of an object to verify a particular method works correctly breaks encapsulation, even if the test is intentionally meant to be friendly with the class it’s testing. This leads to fragile tests and creates a barrier to refactoring.
The focus with RSpec was to make it readable. The writer and reader should not have to remember things like whether the first argument to the assertion is the actual or expected value.
Although Dave Astels jokes that he has until version 1.0 to rename the should method with must it looks like he either lost the argument or changed his mind about it; RSpec is now version 1.3 and should is still being used.
In TDD there is a tendency to create a one-to-one relationship between a class and its test. BDD says that we should be creating specs that verify a particular behaviour, rather than writing tests for each class and its methods. A coverage tool can be used to ensure that all possible code paths have been exercised.
The example that was given for this were the specs for EmptyCollection which might be “should return empty iterator”, “should have zero size” and “should return is empty true”.
Some BDD Frameworks
- RSpec – The BDD framework for Ruby that Dave Astels is talking about in the video.
- JBehave – A BDD framework for Java.
- JSpec – A BDD framework for JavaScript.
- Cucumber – A BDD framework with implementations in various languages, including Ruby, Java, .NET, Flex and web applications.
Please look here for a more comprehensive list.