DaedTech

Stories about Software

By

Improving Readability using Moq

While I’ve been switching a lot of my new projects over to using JustMock, as explained here, I still have plenty of existing projects with Moq, and I still like Moq as a tool. One of the things that I have struggled with in Moq that JustMock provides a nice solution to is the cognitive dissonance that arises when thinking about how to reason about your test doubles.

In some situations, such as when you’re injecting the test doubles into your class under test, you want them to appear as if they were just another run of the mill instance of whatever interface/base you’re passing. But at other times you want to configure the mock, and then you want to think of them as actual mock objects. One solution to that is to use Mock.Get() as I described here. Doing that, you can store a reference to the object as if it were any other object but access it using Mock.Get() when you want to do things to its setup:

[gist id=”4998372″]

That’s all well and good, but, perfectionist that I am, I got really tired of all of that Mock.Get() ceremony. It makes lines pointlessly longer, and I think really detracts from the readability of the test classes. So I borrowed an idea from JustMock with its “Helpers” namespace and created a series of extension methods. Some examples are shown here.

[gist id=”4998277″]

These extension methods allow me to alter my test to look like this:

[gist id=”4998488″]

Now there’s no need to switch context, so to speak, between mock object and simple dependency. You always have a simple dependency that just so happens to have some extension methods that you can use for configuration. No need to keep things around as Mock<T> and call the Object property, and no need for all of the Mock.Get().

Of course, there are caveats. This might already exist somewhere and I’m out of the loop. There might be issues with this that I haven’t yet hit, and there is the debugging indirection. And finally, you could theoretically have namespace collisions, though if you’re making methods called “Setup” and “Verify” on your classes that take expression trees and multiple generic parameters, I’d say you have yourself a corner case there, buddy. But all that aside, hopefully you find this useful–or at least a nudge in a direction toward making your own tests a bit more readable or easy to work with.

3 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Timothy Boyce
Timothy Boyce
11 years ago

Nice, I didn’t know about Mock.Of. By itself that certainly makes tests easier to read. With these extension methods, how would you handle the case where the mock is used, but no specific setup is required? The property would then be null when the unit of work is tested.

Erik Dietrich
11 years ago
Reply to  Timothy Boyce

Oh, I elided the [TestInitialize] method, which I probably should have mentioned. I’ve evolved my standard of test writing to have an initialize method that instantiates the Target before each test. The idea is that if I alter the class under test constructor, I don’t have to incur the maintenance overhead of changing dozens of tests. So I don’t leave it up to some kind of extension method trickery 🙂

Timothy Boyce
Timothy Boyce
11 years ago
Reply to  Erik Dietrich

I’ve started doing that quite often too. With dependency injection the constructor does change quite often.