The Back Burner
March 30th, 2008
Shawn Wilsher: “Most module owners and their peers are often patchers as well. If they have to now write tests for other people’s patches, do reviews in their module, and do patches elsewhere (because nobody who’s a peer or module owner really works in just one module), they are highly likely to put something on the back-burner. Personally, any bug that wasn’t a serious issue that required me to write a test would probably become very low priority (and I suspect that to be the same for most other people).”
That’s the idea. 
March 31st, 2008 at 12:11 am
I just hope there’s room on the back burner, after we put all the second half of the toolkit test requirements announcement, the part where we were going to go through every fixed toolkit bug and write tests for the testable ones by March 2007, thus providing basic tests that the casual contributors would be just tweaking to cover their minor patches, on there.
March 31st, 2008 at 9:52 am
Well, that plan was a little unrealistic, wasn’t it. I don’t think that’s related to my post, though.
March 31st, 2008 at 3:56 pm
Well, I’m not quite sure, but I think so.
I’m sure that the fact that we have entire features that are totally untested (like, say, toolbar customization) means that for a casual contributor (like, say, me), what would otherwise be a trivial fix (like, say, allowing for drops anywhere on the customization palette rather than just inside an invisible box within it, I forget the bug number but I think it’s still assigned to me) turns from something that can be done in an evening into something that can’t be done at all. Given an existing test, I’d be happy to tweak it into testing my change, but without one, rather than having untested better behavior we will continue to have untested worse behavior until someone smarter than me writes the initial test. And I’m not naive enough to think that it’s just now, in crunch time, that nobody has time to write tests for existing features they aren’t in the middle of changing.
I guess if we don’t expect casual contributors to write tests from scratch, and we don’t expect core contributors to write tests for existing features, and we expect core contributors to give writing tests for casual contributors’ patches lowest priority, we can always just count on rewriting everything from scratch, with accompanying tests from the rewrite, to eventually give us test coverage that will allow casual contributors to contribute again
March 31st, 2008 at 4:44 pm
If you fix something and don’t test it, it will just break again.
That’s only momentary progress.