Test Isolation

The strict definition of UnitTest has some people confused about "TestIsolation". For super-high critical software, a unit test should mock out things in other units. The failure of a unit test should implicate only one unit. Most development doesn't require that level of TestIsolation.

DeveloperTests don't need to mock everything, because failing a test case only implicates the most recent edits. (Better, you can revert to throw them away and instantly fix the bug. Gawd, after years of painful debugging, I never get tired of saying that.)

TestIsolation, in both realms, means that effects of one TestCase don't leak into the next case. A rule of thumb is test cases could run in any order (and some TestRig?s enforce that.)

Ideally, we would reconstruct our computers and restart our application between test cases, but naturally we can't. Resetting every global variable to its default state, and rolling back the database with a TRANSACTION, should be enough to get by.

And test cases should be easy to set up. That enforces natural decoupling, to isolate things without mocks.

--PhlIp


EditText of this page (last edited August 31, 2010) or FindPage with title or text search