Tea-Driven Development

As with most stupid questions like this, the answer is “neither”. There are times when integration tests really help, and there are times when they can be a pain in the neck.

I was prompted to write this post when a colleague pointed me towards this page on the behaviour-driven wiki, which mentions the disadvantages of integration tests, which usually involve some complex (and often slow to run) procedure to set up an expected state in the system your code is integrating with. This tight coupling with the external system reduces agility and makes the test code brittle.

The page does point out that “even in this state the code is often much more robust and a much better functional fit than code developed under more traditional methods based on large-scale up-front design”

I agree with the principles in the article, and I believe BDD is a great way to think, but I do think as long as the integration tests are well-factored (and hence easy to change) then the problems highlighted don’t apply – you’re still going to be quick on your feet if requirements change.

The question is whether you’re going to spend more time fixing your unit tests than you would debugging the code – if you’re confident you can write it correctly first time and anybody needing to change it is highly unlikely to introduce bugs in the area you’re coding, it’s a waste of everybody’s time to write a unit test – the test just becomes baggage for the team to drag around.

Conversely, if there’s a risk that future changes could break what you’re coding, or you’re bored of hitting F5 in the browser to test some subtle tweak in a function way down deep in a subsystem, thinking of an imaginative way to write a lightweight unit test that isolates that function and proves that it works as you want it to, is probably going to save you some dull debugging time.

When I sat Mike Cohn‘s scrum-master course last year, one of the concepts I learned was the idea of templating all your user stories like this:

As a [type of user], I want to [do something useful with the system], so that [reason / motivation for wanting to do it].

I’ve come to realise that capturing these three perspectives on any deliverable is actually really powerful stuff. When you break it down, what you’re essentially getting is:

1. who is the stakeholder who wants this work done?
2. what is the goal for the person trying to deliver it?
3. why does the stakeholder want it done?

(1) and (3) really help you prioritize: Does this user really need this? If so, do they need it right now, or is there another feature / story we should be delivering first? (3) especially, can really settle disagreements here, or make otherwise opaque choices become more obvious.

The whole story, but especially (2) gives the developer (or whoever is delivering the work) a clear goal to work towards.

I think it’s far too easy to dismiss this format as wordy and unnecessary, as I did it myself at first. Like so many agile practices though, when I force myself to use it in a consistent and disciplined way, it’s then that the power of it really emerges.

One of the ironies and frustrations I find of working with open-source software is that things are changing so fast (yay!) that the documentation you find is nearly always out of date (boo!).

Trying to figure out how to get the rmagick component of the handy file_column rails plug-in to play nice, I came across numerous gruesome posts involving 3 hour sessions building rmagick from source, sacrificing goats, etc. Yikes.

Then I came across this great piece of news and suddenly things clicked into place. Ahhh.

Ten minutes later, a sprinkle of this, and I have thumbnail images all over my site. Too easy!