First, let me make it clear that I really like BDD, I really like mocks, and I really like dynamic languages. RSpec does a pretty good job of combining all three.
However, there’s one disadvantage that duck-typed languages suffer when it comes to using mocks to drive the design of the interfaces between objects.
One of the persistent themes in my team’s retrospectives is that we don’t pair as much as we should. It’s not that we don’t want to pair, or that something’s stopping us: we just seem too often to lack the discipline to start pairing and then not drift back into working alone again. I’m not sure the best way of avoiding the delay in forming pairs at the beginning of the day and after lunch1, but here’s at least one tip to keep the sessions going.
If you need to quickly nip back to your own machine to check some documentation, google something, check for some urgently-awaited e-mail reply or whatever…
Don’t take your chair with you.
Of course the real answer is to be strict about all production code being pair-programmed, rather than letting yourself make exceptions for ‘trivial’ tasks, or UI code, or refactoring, or something that started as a spike but has somehow grown tests and made it into the trunk…
Wednesday night saw the end-of-year BT Agile Awards dinner, with all the recipients of the various quarterly awards gathering at the Royal Horseguards Hotel to eat, drink, and find out who’d won the overall team and individual awards for the year. It was a good night, made even better by the fact that we won the team award! Our prize is that we’re off to the Agile 2007 conference in Washington DC in August.
Congratulations also to Gregg Wyburn for winning the individual award, and to our current colleagues from the .NET SDK team, who picked up their quarter three award for best application of the BT agile values.
More photos from the night on Flickr (see also photos tagged with btagileawards – hopefully some more people will post and tag photos, but BT’s webfilter blocking Flickr doesn’t help).
From the slightly-odd The Way of Testivus, via InfoQ:
The pupil asked the master programmer:
“When can I stop writing tests?â€The master answered:
“When you stop writing code.â€The pupil asked:
“When do I stop writing code?â€The master answered:
“When you become a manager.â€The pupil trembled and asked:
“When do I become a manager?â€The master answered:
“When you stop writing tests.â€The pupil rushed to write some tests.
He left skid marks.If the code deserves to be written,
it deserves to have tests.
A while ago I wrote about testing trivialities, and claimed that no matter how simple the piece of code is, it still ought to have a test. I followed it up with some thoughts on using a helper to simplify writing specs for common validations. Even using the helper, the actual test code for a single validation outweighs the production code by a factor of more than three:
In case you missed it, those nice people at ThoughtWorks released CruiseControl.rb yesterday.
[Updated 14/3/07: corrected specify_attributes as per Paul’s comment]
[Updated 18/12/07: modified to avoid crazy RSpec errors]
A week or so ago I wrote about writing specs for simple pieces of functionality (particularly those that are arguably just configuration, like Rails validations). I argued that it’s important to test-drive even the simple things – however, the amount of test code can get out of hand.
From time to time I end up in a discussion (as often as not with myself) about the point at which something is so trivial that it doesn’t justify creating a unit test (or behaviour spec, in more BDD-like language).
I’ll get round to watching the whole thing eventually, but first, use the link underneath the video to skip to “What are some of the other principles of Lean?”
I never realised that Tom Poppendieck was such an accomplished ventriloquist!
A recent article in the New York Times describes the issues of introducing ‘The Toyota Way’ to non-Japanese factories.