So far we have covered the fundamentals of unit testing and, as you can readily see, it's not particularly complicated. For unit testing to work, however, it needs to be done from the very beginning. Adding unit testing to an existing project can be very laborious - much more so than if you'd used it from the outset. Even if you do begin by writing unit tests, though, the whole process can become very problematic when you need to incorporate external or internal dependencies in your tests. A common example is database connectivity. If you configure your unit tests to connect to the application's data source, your unit tests may require a certain amount of static data in order to run. If the application interacts with that data then you may find your unit tests start failing. Additionally, if you want to run unit tests in isolation, the methods that require external connections will fail when those systems are unavailable.

Get work around these limitations, mock objects can be used to emulate the behaviour of data dependencies, allowing your test cases to work in isolation. In addition to providing this kind of independence during testing, mock objects can also be used to emulate local classes. By testing with mock objects, you ensure that only the class in question is being tested, without relying upon dependant classes which may or may not be functioning correctly. In other words, mock objects are a way of ensuring that your tests are only testing one thing at a time. Depending on your needs, a handful of mock object frameworks are available for .NET, with NMock being one of the simplest.