One should be able to compile it without requiring other classes, with the following exceptions:
Referencing structs, interfaces and other types are okay.
Referencing system classes are okay.
Referencing utility classes which aren’t considered part of the application logic are okay.
One should be able to test each method independently. When invoking a method, other production classes should not execute. To do this, supply stubs that implement the interfaces used by the class
Stubs should be very simple. When a stub implementation is executed as part of a test, it should do the minimal necessary to fulfill the pass criteria of the test. This is typically as simple as directly testing for the parameter value and returning the expected result.
You will find that as you create stubs to mock various production classes, you end up with many different stubs that all represent the same class being mocked. That is, given a production class that’s being mocked, there will likely be multiple mocked implementations. You may have the urge to consolidate the various stubs into a single sophisticated stub. Avoid doing this because this typically leads to a lot of work, and the stub itself begins to take on a life of its own, and in many ways gets as complex as the production class. For instance, it’s tempting to create a mocked implementation of a database layer which works using XML or CSV instead of a real database. This type of mocking is intended for creating a simulation environment. It isn’t needed for programmer level pure unit testing.
Private classes don’t needed to be tested. They are internal and will end up getting tested when public and protected methods of the same class are tested.