Alan Francis writes about the importance of tests’ ability to tell us when we’ve finished a task. (Thanks, Jason, for the link.)
He reminds us that TDD is about testing, but it’s not just about testing.
For me, the difference between the way I used to think of Test Driven Development, and the way I now think of Behavior Driven Design, is about the responsibilities of the code.
- TDD has always told me whether code does what I said it would do.
- BDD tells me whether code does what it ought to do.
- TDD specifies results.
- BDD specifies behaviour, responsibility, resources and interaction.
Mocks, stubs, and the difference between tests and behaviour
I’ve seen Stubs defined before as Mocks that don’t care whether they’re used or not; they merely provide a context in which code can run. My favourite comparison (who wrote it?) was of a bouncer who is instructed not to let men with a ponytail into a club. To check whether he does this or not, a number of people with ponytails attempt to get into the club, along with a number who don’t have them. As the owner of the club, you don’t actually care whether the bouncer keeps them out himself, or pays a friend to do it; you just care that, when he’s on the door, no one with a ponytail gets in.
The men who enter the club are all Stubs. “Do you have a ponytail?” he asks. And the answer will either be “yes” or “no”. “Are you sure you haven’t got a ponytail? Is that a ponytail? It’s a bit long; does it count as a ponytail?” The Stub doesn’t care how many times you ask; he merely keeps repeating the same answer.
As a club owner, I want to let as many people as possible into the club, as quickly as possible. I’d like to filter out the undesirables, but really, how many men still have ponytails these days? Having one bouncer on the door who checks everyone for a ponytail slows down the queue, so what I think I want to do is to link a ponytail-spotter to the CCTV system, and put him into contact with the bouncer via radio. Now, I still care about keeping out the undesirables – my scenarios, and the acceptance criteria for them, haven’t changed. But it’s no longer the bouncer’s responsibility to spot the ones with the ponytail.
It’s the spotter’s responsibility to spot the tails in the first place, and to say when he sees one.
Now, I already have a bouncer who’s been on the door a while, and I know he’s good at ejecting people from the queue. He no longer needs to check everyone for a ponytail, but he does need to listen to the spotter. The rest of his behaviour is pretty much the same.
What does this have to do with TDD vs. BDD?
Well, when we start to change the bouncer, we know he needs to know about the spotter. It shouldn’t matter to him who the spotter is; all we need to know is that he listens. We make a Mock of a brand new spotter, and test whether he listens to the spotter or not. It is important that he listens to the spotter, which is why the spotter is a Mock, not a Stub. So we get this test, or something like it:
Then we tell the bouncer that the spotter’s spotted something, and check that he responds:
Of course, there’s only ever going to be one spotter, so we can dependency-inject him, passing him into the constructor. (We often do this with Mocks). Alternatively we could arrange some method on the bouncer for making contact with the spotters, so we can add more spotters later if we need them. If we hire more bouncers, we can put all the bouncers in touch with all the spotters. Dependency-inject the spotters as a list, or something. That works. Bing! Green bar. We’re done.
So what would be the BDD way of doing this?
Joel sparked a number of arguments about the definition of BDUF, or “Big Design Up Front”, and whether XP developers did, or didn’t, do it. General consensus appears to be that Agile and XP developers do EDUF, or “Enough Design Up Front” – whatever it is you call it. We often think about things like the domain model, the ubiquitous language, the value of the stories to the customer, etc., before we start to code.
Behaviour Driven Design does Enough Design Up Front to ensure that the behaviour of the class or system is appropriate, before it defines what the results of that behaviour should be. It does provide a specification of those results, but that’s not all it does.
Do you remember those really basic OO lessons? Things like composition = ‘has a’ and inheritance = ‘is a’?
My bouncer should have a radio. My bouncer should not have a spotter.
The likelihood is that when I start thinking about the end result of the bouncer and the spotter, I’ll dependency-inject the spotter.
A better design – and one which is far more extensible, in terms of adding more bouncers and spotters – is to think about who he is, what resources he should have, and how he should use them. Forget about the spotter. I’ll probably do the job myself.
I understand that there are many TDDers out there who would have spotted the need for a radio and sorted it out themselves. Congratulations; you probably do BDD, but I maintain my belief that you are not representative of the TDD community as a whole.
Please note that I don’t have anything against men with ponytails. If you do ever find yourself in London with a ponytail and wish to avoid trouble with bouncers, I may be able to direct you to an appropriate venue. Especially if aforementioned ponytail is black.
The JBehave dev team are currently discussing the use of the term Mock, and the possibility of replacing it with Actor. What do you think? Are you against change of a well established status quo? Is there anything wrong with the term Mock in the first place? Or is it worth nipping this technoslang in the bud now? Comments welcome below!