[Python-Dev] Breaking Test Cases on Purpose (original) (raw)

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/