[Python-Dev] Breaking Test Cases on Purpose

[Tim Peters]

[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 <wink>.