There's a saying in Open Source communities "Patches Welcome". However, I find that some sorts of patches are more welcome than others.
Recently I've been working on putting strptime into POSIX. In response of one of my patches on the perl5-porters@ mailing list, Nicholas Clark wrote me a reply, attached to which was a new set of unit tests, most of which the code did not currently pass, but ought to.
As patches go, this is one of the most useful patches I have ever received. He didn't try (too much) to fix the code, didn't spend that long explaining the problems. He just sent a unit test. Now let me explain why this is useful.
With a unit test script, I can have it run against any version of the code I write. I can run it every minute until it works. I can run it at 3 in the morning during one of my late-night hacking sessions. I can run it on the underground train on my commute to work. It is close, immediate, convenient.
A discussion over a patch to the code alone would be at least an order of magnitude slower than this. People keep different time schedules. People aren't always available online. People don't always get what each other means the first time, leading to more back-and-forth discussion until an agreement is reached.
Without wishing to upset too many members of the Open Source community that might disagree with me, I would say "Patches (to code) Welcome, but unit tests, examples, or documentation would be preferred." I can easily hack up some code to pass the tests you supply, whereas if you just supply some code it's much harder for me to work out what you actually wanted.
very interesting, but can you share example of this unit tests?
ReplyDeleteI generally say something like:
ReplyDeletePlease note that I develop via TDD (Test-Driven Development), so a patch that includes a failing test is much more likely to get accepted (or least likely to get accepted more quickly).
Generally what I want is a test that I can apply first and watch it fail, then code that makes said test pass (and doesn't make any of the other tests fail). If I can only get one or the other, obviously I'll take it, but if I had to pick one, I'd definitely pick the failing test. It's probably much easier for me to make the patch myself based on your test than to make the test myself based on your patch.
Good post.
Yes, I agree. I remember Ori Peleg saying in one of his "Thoughts about Testing" talks, that he's always glad when a bug report includes a failing test case, which is also something I can relate to. On the other hand, I once got a bug report with a patch to the core HTML-Widgets-NavMenu code, which caused some of the existing tests to fail (because it implemented different functionality).
ReplyDelete