[Twisted-Python] Ticket Hall of Shame - Current Loser: Brian Warner
jml at mumak.net
Fri Jan 12 15:11:11 MST 2007
On 1/13/07, Thomas Jacob <jacob at internet24.de> wrote:
> But bug fixes that fix something which is somehow clearly
> (in the responsible developer's view) intended functionality
> that is nevertheless not yet covered by an existing test
> (obviously not ;) are a different matter...
> Expecting twisted users that find such problems in Twisted to also
> submit functional unit test is placing the hurdle
> for bug fixes that get added to twisted quite high.
We don't expect bug *finders* to submit unit tests -- although every
one who does, ROCKS. We do expect bug *fixers* to submit unit tests.
Also, I don't think tests for bug fixes are a different matter from
features. Apart from being excellent descriptions of bugs, tests make
sure bugs stay fixed.
Remember, a bug fix still changes code. If you pile a hundred untested
bug fixes on an otherwise tested module, things get nasty. Suppose I
find a new bug in this module and try to submit a patch to Twisted.
I'd look at the source code and find maybe fifty chunks of code that
seem odd, but can all be changed without breaking any unit tests.
Without unit tests, I'd have no clue that this module was a
particularly difficult module to get right, and that any change I make
is likely to undo a number of bug fixes.
Maybe if I were being diligent, I'd look at the revision history of
the file, and find that out. But then I'd be in a difficult situation.
I'd essentially have to re-think the logic behind dozens of lines of
code in order to insert my patch safely.
Once I did that thinking, I'd write unit tests, because they are a way
of building understanding about behaviour into code.
Of course, I could always just look at the mess and give up, or maybe
contribute a 'helpful' patch that fixes one bug and re-opens five.
More information about the Twisted-Python