Liz Keogh, lunivore

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”.

If you’ve ever been wondering what the difference is between Test Driven Development and Behaviour Driven Design, Dave Astels has written a fantastic paper which explains it all, linked here.

It mentions JBehave, which is still in version 0.0.1 … we’re going to have to do something about that. Soon. I promise.

These are the things I’m learning to love about JBehave while messing around with it:

• JBehave’s MockObject.proxy() is deprecated. You can now cast the mock directly. (With a minor bug to be fixed soon.)
• The aggregate context, event and outcome classes have been renamed to Contexts, Events and Outcomes, respectively. Each one can take two or more Context, Event or Outcome objects. This makes them immeasurably easier to use.
• The whole Context, Event and Outcome framework leads to a more OO framework for story and scenario specifications (no more procedural functional tests!).
• Verify.that(…) is far easier to use than assertEquals(…), and you don’t have to extend anything to use it.
• JBehave’s like that. You can take the mocks, or the behaviour framework, or the story runner, and use them all completely independently of each other. If you have a ‘test’ framework, or a mocking system, or a gui harness, which you prefer to JBehave’s, you can just plug in whichever bits of the JBehave APIs you need to fill in the gaps.

That’s quite aside from the shift in thinking that BDD encourages, which is bigger by far than our little framework.

Looks like LiveJournal are messing with RSS (thanks for the help, Ade). So my feeds are a bit messed at the moment. Normal service will be resumed shortly.

The Yahoo XP group has been having a fairly heated debate about the term “refactoring”. When you refactor, do you change the behaviour of your code, or not? I decided to go have a look on dictionary.com, my ever-ready friend, for a definition.

It didn’t have a definition of “refactor”. It did, though, have “factor”, particularly as relates to the phrase “factor in”:

factor in
    To figure in: We factored sick days and vacations in when we prepared the work schedule.

For me, that implies that the thing associated with the factoring in changes as a result of the new information.

Here’s where Dictionary.com says the word “factor” comes from:

[Middle English factour, perpetrator, agent, from Old French facteur, from Latin factor, maker, from facere, to make.]

We associate the root “fact” with “making things”, like factory. So sometimes I think of “refactor” as “remake”, which usually implies that there was a flaw in the original, or some new requirement, necessitating the remake. That means changing the behaviour.

I guess if you have a “refactoring phase” or you explicitly separate the idea of tidying up the code from remaking it, you might want to insist that refactoring shouldn’t change any of the code. I don’t think of refactoring as a process, and I haven’t found “refactoring phases” useful except as a smell that I’m not doing it enough as I’m going along. I just change things to put new behaviour in, so any “refactoring” I do is usually accompanied by a change in the code.

Refactoring techniques, though, are important tools that mustn’t change the behaviour of my code, because otherwise I won’t be able to control the explicit changes which I’m trying to make. I guess that’s where I see the confusion coming in. Refactoring isn’t a process. It’s just another tool, or a set of them, which lets me maintain my relationship with my code. My relationship with my code involves legibility, maintainability and predictability, and that particular behaviour should never change.

Update: An anonymous friend comments:

That makes sense; I wondered where the original use (ie: non-behaviour-changing transforms) came from. Aren’t words fun?

Ben on the XP thread wrote something which made me smile. I hadn’t seen it before – a Google search attributes it to various people but I suspect it originates with Mark Twain (Update: Apparently Blaise Pascal said it first, but in French):

Whoever came up with that gem, I applaud them. Writing a short, pithy response is far harder and takes longer than splurging everything onto a page. This is how I go about writing shorter responses:

1. I write down all the ideas which the post, email etc. gives me.
2. I work out which of the ideas are relevant to the conversation. I delete the others.
3. I work out which bits of text duplicate ideas, and I delete or reword until each piece of text explains one or more unique ideas clearly.
4. I look at how much text each idea in my post takes up. If the idea isn’t actually worth spending that much text on, I delete the text.
5. I think about how many people are going to read the post. If the remaining ideas aren’t worth their time, I delete the post.
6. I try to get to the previous stage as quickly and ruthlessly as possible. It’s like being a pirate on the seas of your own intellect, which isn’t so bad.

Many of my deleted posts are helpful for me to write anyway as they help me think through my thoughts. I don’t always write shorter responses, even when I should.

I have no idea whether this is a short enough post or not, but if you got this far I must be doing something right.

(Just so I remember)

Which of your projects made you cry at night, and why?

I suspect that our abilities to define exactly why a project made us cry have been shaped by those projects which didn’t. Lack of communcation between teams / leaders, an inability or unwillingness to face reality and / or measure it, and projects of poorly defined or undefined value all made it into this mix.

Use of colour in mind-mapping

Edward de Bono wrote a couple of books: Six Thinking Hats, and Six Action Shoes (one of which I own, but haven’t read yet). Successful mind-mappers sometimes use the six colours as BOIs (Basic Ordering Ideas) in their mind maps, substituting grey for white. Others in the team find it easy to understand the key. Time I read that book.

Performance tests, and how to write stories for them

• Is it even possible?
• Knowing when to stop helps.
• There are different measurements of ‘performance’, eg: processing speed, bandwith use, caching, etc.
• It’s still possible to phrase things in terms of “As a <role>, I want <some outcome> so that <some value>”.
• It’s harder if it’s a pet project and there’s no deadline.

Refactoring the ten commandments

A controversial discussion in which we use agile techniques to remove duplication and make the stone-etched edicts easier and more fun to use.

(XtC)

One of my poems, “A Stitch in Time”, is now online at The Fortean Bureau.

After some struggling, we managed to get our build file working this morning. “Owned! Devs 1, Build File 0”, I thought.

It’s an odd expression, “Owned”, commonly used by gamers and people who read too much PvP. It’s used to express one’s mastery over an opponent in-game, as in, “Ha! I got you with the rocket in midair! You were everywhere! You’re nothing but pieces! I so owned you!” And so forth, though usually with numbers instead of letters.

In this instance, with the slightly less gory game of “Forcing the Build File to Build Things”, the expression “Owned” seemed surprisingly apt. We had managed to get into a position where were were servicing the build file regularly, checking it and pandering to its quirks. It owned us. We were its slaves, even though we were also its creators. We made it to give us an easier life; to provide us with a service. Somehow the roles got reversed. We’ve coerced it into doing its job for a day, but who knows what will happen tomorrow? Will it still behave? or will it, like Homer’s monkey in the Simpsons, lie beered up on the couch, spreading its mess across the room while we run around after it fetching it peanuts every half hour?

I’m firmly on the side of test-driven tools, including Ant Builds. A complex build file often gets changed and altered more than any single piece of the code it builds, and it’s just a domain-specific language, after all. I don’t know how to test it, or what alternatives exist, but I intend to find out. Maybe you can tell me. Somewhere out there is a harness I can use to control these things.

How much of your code do you really own – and how much owns you?

Last week, we had a lunchtime get-together to talk about refactoring the functional tests. This week, we had another conversation about “things that were really good” about the project. A little gem came up between them: CardSuites.

A CardSuite is a suite of acceptance tests which describe a story.

The acceptance tests run as fully as possible, from beginning to end. Now, we have a problem, which is that we’re not differentiating much between stories (ie: additions of features) and bugs (where a story has been misunderstood, or doesn’t fully work, or the story has changed slightly due to business requirements). They all get tagged with the universal “Change Request”, and they all get full acceptance tests written for them. Beginning to end. And this is a huge project – it’s no wonder our tests take 6 hours to run.

Most of the bugs, though, involve only a small deviation from existing behaviour. Writing an entire acceptance test seems like overkill. Sometimes a bug occurs because something’s not being tested – for instance, a message goes to two different systems in two different formats, and only one of them’s being checked. Sometimes it occurs becaue a series of events lead to the domain model being in an odd state. Sometimes it happens because a story is wrong, or being interpreted wrongly. So there are a few ways of automating the test for a bug fix which don’t involve writing end-to-end:

• add a check (or mini-test) to an existing story
• change an existing story to match new understanding (this doesn’t mean, say, changing it to test a more complex process and forgetting about the simple one)
• test the bit which deviates from an existing story.

The last is my favourite. Wouldn’t it be great if we could write a partial acceptance test which starts from a point we know we can get to without any bugs, and end at a point from which we know we can proceed?