Scott David Daniels wrote:
> There has been a bit of discussion about a way of providing test cases
> in a test suite that _should_ work but don't. One of the rules has been
> the test suite should be runnable and silent at every checkin. 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.
There is just one situation that I can think of where I would use this,
and that is the case where some underlying library has a bug. I would
add a test that succeeds when the bug is present and fails when the bug
is not present, i.e. it is repaired. That way you get a notification
automatically when a new version of the library no longer contains the
bug, so you know you can remove your workarounds for that bug. However,
I've never used a decorator or anything special for that because I never
felt the need for it, a regular testcase like this also works for me:
class SomeThirdPartyLibraryTest(unittest.TestCase):
def testThirdPartyLibraryCannotComputeSquareOfZero(self):
self.assertEqual(-1, tplibrary.square(0),
'They finally fixed that bug in tplibrary.square')
Doesn't it defy the purpose of unittests to give them a easy switch so
that programmers can turn them off whenever they want to?
Cheers, Frank
--
http://mail.python.org/mailman/listinfo/python-list
