JUnit and PyUnit, Ignore and expectedFailure

We have a number of failing tests that we've marked ignored at work. There are a couple reasons we don't remove them from the test suite entirely:

Some of these tests are from the 'before times', and they test functionality that was already in production when we got serious about not having failing tests. We want to keep a record of the fact that there's something wrong, but it's not a high priority to fix them right now (since there aren't any customers complaining). As we do more development on things that are priorities, it's easier and less error-prone to make sure that we always return to 0 failing tests, instead of 27 or 115 failing tests, so that we can ensure that everything we do from now on is solid, even if there are older bits that are a bit shaky.

There are also some tests that pass, but we don't want to run on a regular basis. We have a bunch of tests specifically to make sure that we don't fail when you do something that takes ten minutes to run and eats up three gigs of ram. These tests rarely fail in any sense that a test framework would notice, and they slow everything down considerably if you run them during normal development. So we ignore them, and know that if you do anything that has perf implications (or if it's a slow Friday afternoon and you don't think they've been run in a while) you should run those tests to make sure they haven't gotten worse.

Those are the two reasons why we ignore tests that I can think of off the top of my head. It's about what lets you get work done, not about always having everything be perfect all the time.

As a final note, expectedFailure (which I assume is analogous to NUnit's [ExpectedException]) isn't really addressed outside of the title, but its use is completely orthogonal to [Ignore]. Especially for those of us writing APIs, there are cases where we're expected to fail, and it's important that we fail in the right way. If you ask me to save to a file that's locked by another process, I'd better throw an exception, and I might as well write a test to make sure that I throw an exception with a useful type and message.