Handling Broken Tests

Sometimes tests that were running break, and cannot immediately be fixed.

E.g. when new underlying software, such as a new OS release, or a port to a new environment, breaks multiple tests.

Of course one *should* get all the tests running immediately, but that is not always possible.

But at the very least, one should prevent more tests from breaking. You should not be lulled by the known broken tests "Crying Wolf" into ignoring new broken tests that can be fixed.

The TestInventory files are a convenient place to record tests that were run, but which are expected to fail. It may be necessary to keep multiple lists of expected test failures, for different environments.

I don't think this applies to UnitTests, rather IntegrationTests? and AcceptanceTests. A good TestSuite of unit tests will cover all the contracts of the system with minimum overlap. Broken unit tests implies that various contracts are not being met; so resolving these breakages are extremely important.

You can "fix" the tests temporarily by making them into UnitTestAsTickler, i.e. add if(date<next week) return; to them this will make them pass until the time to deal with the issue has passed. This will give you the power of a green bar back without loosing these spefici tests which abviosly deal with insuffieciencies of the OS/underlying SW.

CategoryTesting