Testing in isolation
One of the most important aspects of unit testing is to test in isolation. This does not only mean to fake any external dependency, but also that the test code itself should not be tied up to some other test code.
If you're not testing in isolation, there is a potential risk that your test fails. This is not because of the system under test, but the state that has lingered from a previous test run, or external dependencies.
Writing pure functions without any state is one way of making sure your test runs in isolation. Another way is by making sure that the test creates all the needed state itself.
- Shared state, like connections, between tests is a bad ide.
- Using TestFixtureSetUp/TearDown attributes to set up a state for a set of tests is a bad ide.
- Keeping low performance resources around because they're expensive to set up is a bad ide.
The most common shared states are the following:
- The ASP.NET Model View Controller (MVC) session stat.
- Dependency injection setup...
