7 Sept 2010

Whether the test or the code is more important depends solely on who has to write the tests

In the world of open source development, automated tests are like gold. They're the glue that makes it easy to maintain projects with hundreds of collaborators. When they don't exist, code dies, and nobody knows about it - that would be a bad thing, so preventing it is job one. Unless of course, it means you actually have to write tests for your code, in which case it's delegated just as far down the food chain as possible. And nothing's further down the food chain than a paying customer who's already paid you.

Let's say you paid the author/owner of an open source project to add support for something you need. Let's just say that it's something you need, but that would be useful to him/her as well as others. And let's just say that s/he puts that code in his/her distribution. And you pay him/her for his/her time and effort. All is good.

Then, about six months later, you discover a bug in his/her library, in the very code that you paid him/her to write. You fix the code, and that's a good thing, because you really need it to work. It really should have worked in the first place, but oh well. Shit happens, right?

So then let's say that the code is all hosted on Github [because this hypothetical case happened in 2009/2010 and anything worthwhile is being hosted on Github], that you branched the main project, made your change, and committed it. Then you send a pull request to the project maintainer explaining the situation. Beautiful, this is exactly how open source is supposed to work. Git is wonderful, Github is fantastic, and everything just works because of it.

And you get the answer back from a minion of the author that you paid: "well, no, we can't accept this change, because you see, there is no test that was broken in the first place, and no new test has been written to prove that this change is a good one. So go write a test and then we'll think about it."

Which strikes you as a bit odd, because hypothetically, if s/he wrote the code in the first place, and s/he/they is/are such [a] holy motherfucking test-first code ninja[s], s/he would never write a line of code without tests for it. Except the evidence is in the code that never worked in the first place (despite your having, er, paid for it).

So now you have to maintain your own branch of this stuff in perpetuity, because they have rules, you see, and standards, and these rules and standards say that they won't accept changes that don't fix tests. Oh, and by not accepting your fix they're actually hurting your reputation, because the fact that the stuff they wrote for you doesn't work with their library might look like it's your fault, not theirs. But you paid them, and it's all over now. Unless you want to try to write a test for them, which they'll consider accepting.

What you might expect from the maintainer would be an apology, a gracious acceptance of the fix, and for him/her to write the test s/he should have written in the first place (if that's what makes him/her so goddamn happy).

Purely hypothetically speaking. I mean, it would be totally inappropriate to name names if this actually happened.