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)