Hurray for tests: preparing a buildout pull request¶

Tags: python, buildout, django

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!

• Having tests means getting quick feedback on what you’re doing. “Does this break something?” “Does this still work?”
• Writing a test first, before writing any code, also works nice if the code lends itself to that method. It is fun to write a test; see it fail; add the actual code; see the test run. Psychologically it gives you a success feeling, which helps keep up your momentum. You set yourself up for getting a pat on the back from yourself. When you get the pat on the back, you’re happy! Even if you set it up yourself. Human psychology is weird :-)
• Having a good amount of existing tests is important. Would I have set up the entire test machinery from scratch to add this one feature? No. Would I have gone through so much testing effort for one feature? No. The existing tests make it possible and logical to test any new feature well.
• Having a good amount of existing tests also means the buildout authors can rightfully expect tests when somebody submits a fix or a new feature. I see the same with Django: everything is so well-tested there that nothing is accepted ito core Django without proper tests. (And also not without proper documentation, which is something I admire about Django!)

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”.