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

Tim Peters tim_one@email.msn.com
Thu, 3 Aug 2000 14:49:02 -0400

[Moshe Zadka]

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?

The XP answer would be "hey, you have to checkin the breaking test case right away", and I'm inclined to agree.

It's abhorrent to me to ever leave the tree in a state where a test is "expected to fail". If it's left in a failing state for a brief period, at best other developers will waste time wondering whether it's due to something they did. If it's left in a failing state longer than that, people quickly stop paying attention to failures at all (the difference between "all passed" and "something failed" is huge, the differences among 1 or 2 or 3 or ... failures get overlooked, and we've seen over and over that when 1 failure is allowed to persist, others soon join it).

You can check in an anti-test right away, though: a test that passes so long as the code remains broken .