Speaking at Software 2007
The BDD cargo cult
The BDD buzzword (Behaviour-Driven Development) has caught on quite nicely. Unfortunately a lot of people seem to think it’s about syntax, which it is not.
Writing things like context and specify doesn’t mean you’re doing BDD, just like writing tests doesn’t mean you’re doing TDD.
There are other features of RSpec than its syntax that makes it a BDD library.
Expressed intent and Testdox-like reports
Writing specs (or examples or tests) that serve as documentation and at the same time reveal the intent of the code is a common practice among seasoned TDDers. BDD defines this practice as mandatory. RSpec makes the practice easy to follow (using context and specify). The point is – any syntax is fine. You can follow the same practice using FIT or JUnit (or one of the dozens of clones), a naming convention and a reporting tool like Testdox that can generate something like this:
A full stack
- should raise an exception on push
- should allow a pop
RSpec also makes it easier to express intent in the code itself, using constructs like
name.should_match /lak/
Again – this syntax makes it easier to write code that follows the BDD philosophy, but it isn’t – per se – BDD.
Just using context, specify and should_* without understanding that the key points are to express intent and to make it visible won’t bring you more than somewhat nicer syntax. BDD is a technique, not a syntax.
Mock objects
Webster’s definition of “behavior” says: anything that an organism does involving action and response to stimulation.
Code designed according to BDD (at least down at the code level) lets you verify what an object does in response to stimulation (calling a method on it). It’s not about looking at return values from that method. It’s about verifying what other objects the stimulated object communicates with.
This is where mock objects come in. Mock objects (connected to the object you poke at) tells you that. Without mock objects it is terribly hard to know what an object does – you don’t know much about its behaviour. So what a lot of people do instead is to use state-based testing That is fine too, but it ain’t BDD.
So here is an appeal to all of you creating “BDD” libraries: Does your library make it easy to communicate the overall responsibilities of the code? Can you use the library to express behaviour?
If not, chances are you’ve just created an RSpec clone, possibly promoting the BDD cargo cult