[Python-Dev] Breaking Test Cases on Purpose
Greg Stein
gstein@lyra.org
Thu, 3 Aug 2000 10:04:01 -0700
On Thu, Aug 03, 2000 at 07:44:28PM +0300, Moshe Zadka wrote:
> Suppose I'm fixing a bug in the library. I want peer review for my fix,
> but I need none for my new "would have caught" test cases. Is it
> considered alright to check-in right away the test case, breaking the test
> suite, and to upload a patch to SF to fix it? Or should the patch include
> the new test cases?
If you're fixing a bug, then check in *both* pieces and call explicitly for
a peer reviewer (plus the people watching -checkins). If you don't quite fix
the bug, then a second checkin can smooth things out.
Let's not get too caught up in "process", to the exclusion of being
productive about bug fixing.
> The XP answer would be "hey, you have to checkin the breaking test case
> right away", and I'm inclined to agree.
>
> I really want to break the standard library, just because I'm a sadist --
> but seriously, we need tests that break more often, so bugs will be easier
> to fix.
I really want to see less process and discussion, and more code.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/