Liz Keogh's blog

I’m increasingly coming to believe that there’s no such thing as a bad idea. They tend to generate good ideas, or cause changes which help to generate better ideas in future. The only danger is that occasionally, bad ideas get put into practice. That’s why I’ve taken to blogging my ideas before I go ahead and accidentally plunge the whole world into fire and damnation, when all I really wanted was a faster toaster.

Behaviour-driven-design advocate Manish and I have just had a chat over IM. He’s pointed out to me that checking things after the event is just testing, whereas anticipating things before the event is design. Design is good. Bugfixing is a pain.

On the back of that discussion, I’m thinking that JBehave’s Story Runner should probably run a scenario as follows:

Given a context
Then this outcome should occur
When an event happens.

Which ties in nicely with the “should” mechanisms / language of JBehave.

I may, given the JBehave team’s permission (or without it, even, ‘cos it fixes a bug I need fixing) refactor the scenario invoker to perform the above steps, and write a scenario verifier which checks that the anticipated outcome occurs.

I still can’t check that a given method got the arguments after the event. Maybe you should be able to “store” an expected method call on a mock by a key, or some kind of id, so that you can check it afterwards? In fact, I think JBehave’s Minimock already does this… hmm…

JBehave’s Story Runner runs through scenarios as follows:

Given a context
When an event happens
Then this outcome occurs.

So you’d think it would visit these in the order “context, event, outcome”.

Unfortunately, the mocks all have to be set up before the event – so what you actually get is “context, outcome (setUp), event, outcome (verify)”.

What’s more, when you come to replace the mocks with real code, expectations in setUp become checks in verify,
eg: mockHellboundGui.expects("setVisible") before the event becomes assertTrue(swingHellboundGui.isVisible()) after the event.

The expectations are a kind of verification anyway. Wouldn’t it be great if you could set them up in verify, instead of setUp? If you could just create mocks in setUp (or even in the event, perhaps, where you use them), then add all the expectations at the end, after the methods have been called but before you call mockFoo.verify()? You wouldn’t do expects("setVisible"), you’d do expected("setVisible") instead.

This would also help with another problem I have; where the (real) Hellbound game factory creates a game, but I can’t expect the game to be passed to the arguments of any of my mocks as I didn’t have hold of it in setUp.

Unfortunately all the current mock schemes insist on you expecting a method before it gets called, or they fall over. What a pain.

Today I wrote my first TDD test (with help from my pair partner, obviously). It was fun watching it fail, then fixing it so it failed the way we expected, then fixing the code to make it pass. The code works. The test works. I feel a surge of enthusiasm now that I have a green bar, and I would like to share this special moment with you all.

Small steps.

Today I wrote my first proper Wiki page.

I did this because someone gave me a set of instructions in the form of some scribbled notes, and I realised that I’d need to write them down to make head or tail of them later. So I spent ten minutes putting them in the development Wiki, and five minutes making them legible.

Presumably the knowledge of the mystical process I’ve documented has been passed down on the project from generation to generation, with each successive wave of new developers learning from the one before. I feel like Charles Perrault; taking a thin slice of legend and trapping it in a palatable form which won’t offend young children. There are probably nuances, exceptions and warnings which changed the story with every telling. All these are now lost to posterity because you know that no one who knows the stories by heart will ever read them or add to them.

Three months from now, two young and inexperienced developers will be talking around the coffee machine. “Why did you do it that way?” one of them will say. “I don’t know,” says the other. “It’s what it said to do in the Wiki.”

With a little effort they’ll be able to track me down as the author, but I won’t know either. No one will try anything different as we all know that this way works. And thus another inexplicable procedure enters the development process; a strange tale built around a greater truth long lost in the mists of time.

Talk to your grandparents. Listen to what they say. One day they’ll leave the project for a better place, taking their wisdom with them.

The first program other than HelloWorld which I ever wrote in Java was a very simple version of Tetris. My OO design was nonexistent, but it enabled me to explore the language and trawl through the APIs. Goodness knows where the source code went. It was a while ago.

For a while I have wanted to rewrite the game, mostly to practice OO design, but the years have ticked over and I have different priorities. I can’t pair program at home without developing multiple personality syndrome, but there are other agile practices, technologies and concepts which I want to work with. JBehave is currently top of the list.

I’m a writer and a poet. The idea of being able to use natural language to develop code appeals to me immensely. I am therefore in the process of speccing out a version of Tetris called Hellbound (I hope eventually to get a GUI consisting of fallen angels and demons being dropped into a fiery pit). I want to develop the specs as I go along, using JBehave to help me determine the responsibilities of each class and to test their behaviour. This could be interesting, since JBehave is, um, a little lacking in documentation at the moment (want any help with that?). I’m hoping to practice other things such as: dependency injection, refactoring, testbehaviour driven development, etc.

Thanks to Chris, Dan and Manish for their patience with me so far. I’ll let you know how I get on!

After reading Chris Matt’s comments on interfaces, I started noticing all kinds of FooImpl classes in the code over here. As far as I can tell, the only reason for using …Impl for a class name is because the Foo interface only exists to be mocked – so the implementations are FooImpl, MockFoo and any other one-off Foo implementations used in testing.

I like ‘real’ names. I’d prefer to see classes named, say, DefaultFoo or SimpleFoo or BasicFoo instead. FooImpl feels clunky, especially if it’s still there after AdvancedFoo and QuickFoo are created. Is this a good thought, or am I missing something?

These thoughts mostly prompted by reading about PicoContainer, which is cute but seems to promote the naming pattern.

Update: there are better names than DefaultFoo (thanks for anonymous advice)