Liz Keogh, lunivore

That’s the skyline from our Holborn office this morning – the London Eye, the south bank of the Thames, and Big Ben and the houses of parliament on the right. My little phone can’t capture the full magnificence of watching the sun rise, but I hope this snapshot gives you a glimmer of inspiration today.

Snow on the way.

For anyone who’s following the whole kafuffle over Microsoft and their recent misdescription of TDD, you may be glad to know that it’s been removed, and will hopefully be rewritten following feedback from the Agile and TDD community.

I remember an old geek joke: “How many Microsoft Engineers does it take to change a lightbulb? None; they just declare darkness to be the industry standard.”

The world is changing in some strange and beautiful ways. I’m still going to buy myself one of these, though. Champion of the Underdog, that’s me.

Yesterday, during some excellent conversations with the XtC, I found myself thinking about the “one assertion per test” rule which Dave Astels proposed, and which many people advocate for Test-Driven Design.

I think it’s important that each method in a test should test only one thing, but sometimes I find it’s more helpful to use a couple of asserts to do that. For instance:

public void testShouldHavePopulationOfOneWhenOnePigeonAdded() {
    PigeonCoop coop = new PigeonCoop();
    coop.add(new Pigeon());
    assertEquals(1, coop.getPopulation());
}

public void testShouldHavePopulationOfTwoWhenTwoPigeonsAdded() {
    PigeonCoop coop = new PigeonCoop();
    coop.add(new Pigeon());
    coop.add(new Pigeon());
    assertEquals(2, coop.getPopulation());
}

could be replaced by

public void testShouldHavePopulationEqualToTheNumberOfPigeonsAdded() {
    PigeonCoop coop = new PigeonCoop();
    coop.add(new Pigeon());
    assertEquals(1, coop.getPopulation());
    coop.add(new Pigeon());
    assertEquals(2, coop.getPopulation());
}

The names of the methods at the top describe ways in which to verify that the PigeonCoop, once coded, works as expected. The name of the method at the bottom describes an aspect of the behaviour of a PigeonCoop (and serves as a reminder to myself that ‘should’, while magic, doesn’t automatically lead to Behaviour-Driven Design.)

One of my friends asked me for some advice about how he could change his life. “I’ve come to the conclusion,” he remarked, “that I will never be happy unless I’m making a living as a musician.”

“Well,” I said, “you might as well go for it, then. The worst that can happen is that you’ll fail, and be only as unhappy as you are now.”

So he did. He’s now the drummer for a band called The Modern. They’re playing gigs almost every other evening and he says the schedule’s quite exhausting, but when you see him play you just know he’s having the time of his life.

The Modern’s new single, Jane Falls Down, hit the UK charts at number 35 this week. If you’re into solid performance, dance beats, gorgeous glam, exquisite electropop, new experiences, or the kind of tunes that play themselves repeatedly in your head for days, go get it – downloadable from iTunes and MSN, and available in all good record stores except mine, which had annoyingly sold out.

Do you hate your job?

What kind of job would you like to do instead?

Why aren’t you doing it?

Sometimes it’s very hard for me not to get involved when I see a problem. Like many people, I’m a bit of a control freak. I like to know that all problems will be solvable; that the future is rosy; that I won’t be surrounded by unhappy colleagues in the morning; that I won’t ever have to say “I told you so” just because I couldn’t get someone to listen. If I find new patterns which can be used to solve things, I tend to want to share them with everyone.

Following advice, and the timely intervention of external forces, I have been trying out Silence; a highly effective problem-solving process. I have had such success with this that I want to share it with you.

There are many core practices which make up Silence. Here are the ones which have worked for me.

1. Get plenty of sleep and downtime. This helps your concentration, and means that you have reserves of energy. These are important. Without reserves, you are less able to adapt to change, and will therefore feel an insane urge to control everything around you. This will make you want to speak (see part 3. )
2. Find a really nasty cold and fall ill with it (there’s one around the office somewhere). The future will become someone else’s worry as you struggle with the present. You may also lose your voice. (You will not need to do this if you follow part 1. )
3. When you want to speak, don’t. Wait until there’s a space to speak. When the silence comes, forget about speaking – just listen to it. There will be another time to speak. Try to get at least one piece of silence between each thought, and voicing it, if you can remember what it was. You may be forced to let some thoughts slip by unvocalised, but take confidence from my promise that it’ll be worth it in the end.

The results of my limited experiment have been astonishing.

1. Firstly, I’ve realised that most of the problems I spot are not unique to my own insight. I do have unique insights, but so far, I’m spotting one every couple of days or so. That’s a lot less time than I spend talking. If I treat each of my insights as an opportunity to let someone else speak first, then the rarer thoughts become easier for me to spot.
2. Secondly, I sometimes learn things in the time of not speaking which change my insights. I get time to reflect on them, and to work out how to phrase them in the best way, and at the best time.
3. Thirdly, I get so much more respect when I finally do speak. When I say things, they’re more often things that no one else has said.
4. Lastly, and most importantly – those people who don’t speak often seem to say the wisest things. They’re very interesting people to listen to. If I don’t speak, then they have an opportunity to do so.
   I’ve learnt so much from these people that I want to be one of them.

All of this is common sense, but it’s so much harder to put into practice than it should be. We ThoughtWorkers are often seen as an arrogant bunch, and not without reason; it takes courage (or the intervention of external forces) to give up control, and a certain level of trust in your colleagues and customers to let them take it from you. I’m learning, and it’s an interesting, if bumpy, ride.

A number of people have been instrumental lately in seeing me through recent challenges and uncertainties. Thank you is always worth saying, so to everyone who’s taken the time to help me and put me in touch with my inner owl: please accept my gratitude and respect. It’s rare to feel both humbled and uplifted at the same time.

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.