Just A Summary : Tag tdd, everything about tdd

Baby's first screencast

pdcawley@bofh.org.uk (Piers Cawley) — Fri, 14 Mar 2008 14:29:00 -0500

If you follow the Ruby blogs, you will probably have seen a bunch of programmers attempting to do something akin to Haskell’s maybe, or the ObjectiveC style, message eating null.

Generally, by about the 3rd time you’ve written

if foo.nil? ? nil : foo.bar 
  ...
end

you’re getting pretty tired of it. Especially when foo is a variable you’ve had to introduce solely to hold a value while you check that it’s not nil. The pain really kicks in when you really want to call foo.bar.baz. You can end up writing monstrosities like (tmp = foo.nil? ? nil : foo.bar).nil? ? nil : tmp.baz (actually, if you were to write that in production code, you probably have bigger problems). One option is to just define NilClass#method_missing to behave like its Objective C equivalent, but I’ve never quite had the nerve to find out how that might work. I wanted to write

if maybe { foo.bar.baz }
  ...
end

and have nil behave like an Objective C nil for the duration of the block, but no longer. So I wrote it. Then I thought about how to present it. I wrote the thing test first using rspec and the whole thing just flowed, but writing up a test first development process for a blog entry is painful, so I’ve made a very rough (but blessedly short) screencast of the process instead.

That’s a slightly reduced thumbnail, the movie is substantially more readable. The bottom pane of the window is the output of autotest rerunning the spec every time either the spec or the implementation changes. The top pane alternates between the specs and the implementation. Generally, every time I edit the specs, a test starts failing and every time I edit the implementation it starts passing again. In the (any) real coding run, there were of course false starts, but generally the specs kept me pretty straight.

A word or two of warning: This is a completely unedited, silent, screen cast, there are typos, backtrackings and other embarrassments. I stopped recording once I’d got 4 tests passing, but this is far from release quality (it’s perfectly usable if you know its limitations, but it’s not entirely robust).

Please let me know what you think of this. I’m aiming to make a more polished version, complete with voice over and it would be good to know which bits are confusing and need addressing in more detail in the voice over.

Other viewpoints, and why they are important

pdcawley@bofh.org.uk (Piers Cawley) — Wed, 16 Aug 2006 02:50:00 -0500

Many thanks to Paul Ingles who has just written a fantastic article about writing a Typo sidebar in a test driven way.

For too long we’ve been assuming that Typo sidebars are, in fact, detestable (“If it’s not testable, it’s detestable” – someone at the Sydney XP group, by way of Martin Fowler). Paul neatly demonstrates that sidebars are perfectly testable, we just haven’t been testing them. Bad us.

So, I’m rolling back the changes in my current sidebar rejig and starting again by writing some tests for a few of the core sidebars, and then I can start my refactoring without quite so much of The Fear.

So, once again, thanks Paul. It’s really great to occasionally see the curious outsider’s view of what we’re working on – it makes us question our assumptions and often shows us better ways.

If you test it, I will patch

pdcawley@bofh.org.uk (Piers Cawley) — Sun, 12 Mar 2006 13:17:00 -0600

I’ve been working on Typo this weekend, mostly going through open tickets and deciding whether to apply patches.

There’s plenty of potentially good patches in the queue, but too many of them give me The Fear.

They don’t have tests!

I’m the first to admit that I’ve added untested code to my projects (and I’ve been bitten by it too), but I’m more sanguine about that risk because, when it goes wrong, I can often rack my brains and pull back some memory of what my intent was. Knowing my intent helps me write meaningful tests and fix the issue. However, I can’t remember the intent of your code. The only thing I have to go on is what you wrote. If you’ve written tests, I can tell what you expect your code to do, which is far more important than being able to divine what your code actually does. Given a choice between code without tests and tests without code, I’ll take the tests every time.

So, if you’ve got a typo patch on the trac and you want it to get accepted, you must write tests for it. If you’re implementing something that’s supposed to be conforming to a standard, then please reference those standards in your tests.