Liz Keogh's blog

Have you ever had a new, slightly fragile idea be damned by someone playing Devil’s advocate?

There are ten other personas to oppose him. Next time you hear someone take on the role of a hell-bent lawyer, try one of these roles. Fire-retardant costumes not supplied.

John on the XP group pointed us to this post by Jeff Bigler on Tact Filters. I found it quite an entertaining insight.

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:

mockSpotter.expect("addListener").with(bouncer);

Then we tell the bouncer that the spotter’s spotted something, and check that he responds:

mockSpotter.expect("getPonytailDirections").willReturn(locationOfPonytail);
assertTrue(bouncer.isInFindPonytailMode());

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.

Notes

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!

If an Agile Evangelist falls in the forest and there’s no one to hear him, does he still go on, and on, and on about it?

(Not thinking of anyone in particular, unless it’s me.)

Another conversation on the XP Group.

Why do some people manage to have successful projects without using Agile methodologies, while others who are using XP still fail?

XP is a toolbox. Think about a mini project in which you need to remove a shelf from a book case in order to put taller books in the space.

A bad workman will always blame his tools. If the book case is still without a shelf for tall books after a day, he’ll tell you it was because he couldn’t find an appropriate screwdriver.

A good workman will find the best tool and improvise. A good worker might use a nail file if he can’t find a screwdriver.

I wouldn’t recommend using Waterfall any more than I’d recommend using a nail file to get the screws off a bookcase. You can do it, but it’s ugly, it takes ages and you’ll bleed before it’s done.

Reading the latest posts on the Yahoo XP group, it seems that good TDDers understand that the word “test” is developer-speak for something a little more complex. “Test”, in Test Driven Development, encapsulates the idea of specification, design, verification of implementation and the ability to confidently refactor. Regression testing itself is almost a by-product of these uses of the word “test”. “Test” is often the first word we think of when doing TDD – you always start with a test – and yet we use it in defiance of its own definition.

I believe that the word “should”, and similar elements of Behaviour Driven Design vocabulary, remove the developer-speak, thus helping to bring the code closer to those people who aren’t privy to the secret language of software. This includes the customers, and anyone who isn’t familiar with TDD.

I believe that the inclusion of developer-speak such as “test”, which no longer means what it says, allows us to easily utilise developer-speak in other ways without noticing. We use other laden terms such as “mock”, “stub”, “functional test”, “…Impl”, etc. We find ourselves free to name classes after the patterns they mimic and the classes with which they interact (ScalpelSheepVisitor) instead of capturing their role succinctly (Veterinarian). We refer to documentation blindly (JIRA345Test.testHappyPath()). We don’t make readable, legible code.

Sometimes, because we can’t read our code properly, we mix up the roles and the responsibilities of our classes (ScalpelSheepVisitor shears the sheep too). We assign responsibilities to classes which don’t really have responsibility for them (SheepVisitor.getCostOf(sheep)), and we verify that these new responsibilities work (testCostOfSheepReturnedSuccessfully) instead of considering whether they’re appropriate.

For people who are already aware of these pitfalls, and who use TDD with care, mindful of what the word “test” really means – BDD will bring little that’s new into your life.

For everyone else – try thinking of these things when you code. Don’t test; think “What should this class do? What are its roles and responsibilities? What does it do to the things I’m going to give to it?” Then write a method which will describe the class’s behaviour. If you need a prefix on the name of the method to make it run then write it, but don’t type those letters until the real name has come to you.

I find that using the word “should” helps me think of the name. I find it helps me consider the roles and responsibilities of the class, and the class’s interaction with others. I find it keeps me away from that distracting, misleading, misnomer: “Test”.