Paul Rubin wrote: > > Recently there was a checkin of a test that _should_ work but > > doesn't. The discussion got around to means of indicating such > > tests (because the effort of creating a test should be captured) > > without disturbing the development flow. > > Do you mean "shouldn't work but does"?
no, he means exactly what he said: support for "expected failures" makes it possible to add test cases for open bugs to the test suite, without 1) new bugs getting lost in the noise, and 2) having to re- write the test once you've gotten around to fix the bug. > Anyway I don't understand the question. it's a process thing. tests for confirmed bugs should live in the test suite, not in the bug tracker. as scott wrote, "the effort of creating a test should be captured". (it's also one of those things where people who have used this in real life find it hard to believe that others don't even want to under- stand why it's a good thing; similar to indentation-based structure, static typing, not treating characters as bytes, etc). </F> -- http://mail.python.org/mailman/listinfo/python-list
