[Python-Dev] Breaking Test Cases on Purpose

[Michael Hudson]

Moshe Zadka <moshez@math.huji.ac.il> writes:

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

I'm not so sure.  I can't find the bit I'm looking for in Beck's
book[1], but ISTR that you have two sorts of test, unit tests and
functional tests.  Unit tests always work, functional tests are more
what you want to work in the future, but may not now.  What goes in
Lib/test is definitely more of the unit test variety, and so if
something in there breaks it's a cause for alarm.  Checking in a test
you know will break just raises blood pressure for no good reason.

Also what if you're hacking on some bit of Python, run the test suite
and it fails?  You worry that you've broken something, when in fact
it's nothing to do with you.

-1. (like everyone else...)

Cheers,
M.

[1] Found it; p. 118 of "Extreme Programming Explained"

-- 
  I'm okay with intellegent buildings, I'm okay with non-sentient
  buildings. I have serious reservations about stupid buildings.
     -- Dan Sheppard, ucam.chat (from Owen Dunn's summary of the year)