Last week, I prepared a pull request for zc.buildout 2.0 to include buildout-versions’ functionality in buildout itself. I had looked at the inner workings of buildout before and even prepared a pull request before, but that was a small one.
buildout-versions monkeypatches internals of buildout so that it can print a list of picked versions at the end of your buildout run. Quite essential if you want to make your buildouts repeatable. You don’t want too many surprises by new versions.
So: I integrated a buildout extension that did some buildout-monkeypatching into buildout itself. More specifically into a historically quite involved piece of buildout. Picking the right versions is at the core of buildout, so making a mistake there is a big no-no :-)
Where did I get the confidence for making such a pull request? From the tests.
There are a lot of tests in buildout’s code. They’re mostly doctests. Doctests have their drawbacks (and advantages). But they’re tests anyhow. And I could find a couple of good spots to add my documentation and tests to test the functionality I was copying over from buildout-versions. And I could be certain that if I broke something, the existing tests would tell me. Nice!
Testing? I see it as something that helps and motivates me. Provided there’s a pretty good amount of tests. And provided I don’t have to clean up somebody else’s junk because they don’t care about tests. In those cases, it becomes a chore. It can also become a chore if an application has too many dependencies or isn’t structured so that tests become easier. In those cases I keep to the mantra “applications that are well-testable are also well-structured”.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):