Failing unittest Test cases

[Frank Niessink]

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