Liz Keogh's blog

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?