Set the Hack Free #1 : Lazy Regression Testing for Perl.
I've got a couple of notebooks and many more loose papers with ideas for hacks that I never get around to implementing. This seems like a waste. So I've decided to start taking some of them to write up here, include any skeleton/stub code I've written and then basically purge myself (and my svn sandbox) of the burden of trying to hope that I'll get around to doing a decent implementation one day. This is the first such hack idea, so be free little hack idea, fly, fly like the wind!
I'm lazy (Larry says thats ok, although he also says that you should be dilligent – but lets ignore this) and because I'm so lazy I like the computer to do my work. Although I'd still like to get the salary/rewards - the computer would just blow it on more SLI graphics cards (bizarrely Nvidia now sell clothes) and those fancy neon case mods.
Anyway, I was thinking about regression testing one day, especially the problem of using Perl in big organisations. Imagine a programmer, lets call him Dave, now Dave has just knocked up a great new program that needs to go into production, it uses use one module – Acme::Shiny. The good news is that Acme::Shiny has already been installed on the production servers and LOTS of programs use it, the bad news is that Dave being uber-keen needs the latest shiniest version of Acme::Shiny to use the new method do_super_shiny_thing(). The problem is how do you know that the author of Acme::Shiny hasn't decided to break the interface for all the other programs that already use it.
And did i mention that Dave is the CEO's nephew and for entirely unrelated reasons the CEO is really keen to see this program go live.
Now you could go and look at the interface by hand (and at some point you should), but this becomes difficult especially if its not just Acme::Shiny that you are worried about – imagine that it also uses the bleeding edge versions of Catalyst and Plagger and their one or two dependencies.
So what is my hair brained solution for this? Whenever you install new software you keep its test suite, so somewhere you have the tarball for your installed Acme::Shiny (or you could grab it off CPAN). When it comes to the new version you run the tests as normal, but then you delete them and copy the tests from the old and installed module. If you are lucky when you run these old tests they check the old/expected interface reasonably well – and any change of interface will be spotted by the previous tests failing.
Of course this is far from fool proof, but like most tools its simply there to help you do your job a little better.
Anyway hopefully this idea is more useful here rather than in my notebook.

It's always a bad sign when I have to start by explaining why I did something.