I prefer to have a helper method:

public static TService EnsureNeverCalled()
{
var mock = new Mock(MockBehavior.Strict);
return mock.Object;
}

I also like to add a number of Guard clauses to the constructors of my objects – to ensure that no null dependencies are passed through. These guard clauses only verify method arguments as not null, not empty and (to a lesser degree) specific conditions. See http://ajdotnet.wordpress.com/2009/08/01/posting-guards-guard-classes-explained/

Any method that uses multiple return points is another example. Sometimes leaving those multiple return points together is better for the overall design.

I agree that the ProcessPayment() method as shown above is not optimal. I would probably refactor out some of the responsibilities myself. But, there are simply some classes that cannot be refactored.

As to the NullReferenceException that will come from erroneously using the null dependencies, I would rather have that than a more obscure failure. For example, a default stub might return null or swallow a call to a void method. This may or may not cause an error in the test. In my experience, when these tests do fail because of the default behavior of the stub, those errors are more difficult to debug than a NullReferenceException with a stack trace that points directly to the problem.

At the end of the day, much of this is simply preference. I’m not strictly dogmatic about using named nulls when I have to, I simply like that option better than unnamed nulls or automocking containers.

While it is certainly possible to have unused dependencies in your ctor, it is unwise to code your tests as if you know that, or any of your code, for that matter. That implies that your class is doing too many things at once, and that it is not very cohesive. It is also an indication that you are testing against the private parts of your system, which is incredibly vulnerable and brittle.

Another point that I’ve realized lately (not necessarily all that related to the post, but definitely to some of the comments) is that null should never be passed into the ctor of an object. This implies that the outside world knows when a certain dependency doesn’t need to be there, and that defeats the purpose of encapsulation.

IMHO. If this null behavior is not so important for you you should remove it from test and if it is you should create a new test for that null behavior and appropriate name.

Nikola Malovic

The reason I see the test as less than desirable is because if the test doesn’t care about the RequestFunds() method why should we document it in the test? This could easily cause the test to become brittle. Why make a test depend on something that has nothing to do with the success or failure of the the unit in question?

For example, if a parameter was added to the RequestFunds() method then this test would not compile and we would have to fix it before continuing.

In an isolated case it doesn’t look like a big deal but on a larger scale, with a few thousand tests, you could see how the cost of maintaining the tests go up and the original intent of the test becomes less clear.

Good post!