VeST Redux – What’s so wrong with mocking frameworks?

While working on a project, on a nice summer day, and after many hours of frustration and disbelief at my incapacity to make sense of some test code using a mocking framework, I expressed an opinion I wanted to share with you.

Mocking frameworks are actively harmful, and probably infringe on my human rights.

It’s not just a matter of taste, there are fundamental issues that make it harder to design good and maintainable software.

They lead to code duplication

The code starts simple enough, you write a class, you mock the first interface’s method it implements, test pass, you move on to your next test.

After you write 50 tests, you end up with 50 implementations of the same method, littered all over your testing code. Some will argue that it’s just a matter of reusing and refactoring your test code. If you’re going to reuse your mocking setup, then…

They are a poor way to implement a class

I already made that point a long time ago: mocking frameworks are a poor way to implement fakes. The code is noisy, with some frameworks it does not refactor well, and let’s face it, no amount of magic will compete with writing classes in an actual language.

If you have a one-off method on one interface that has 50, and you are already in hell, maybe a mocking framework will help you. Those cases are rare and don’t explain how often these things get used. Given the choice, I’d split the interface into smaller chunks, and test that. It’s easier and result in cleaner and simple code, and seggregates functionality as you refactor.

They often introduce incorrect contracts

The author of a class or interface is the closest to knowing the contract. Understanding when the code throws, what arguments can be null or not, and what values will cause error is a matter for the contract author to define. This is done in documentation, type systems and / or pre/post conditions.

When you fake an interface you don’t own, you have to re-implement this contract, and often you will not know enough to implement this correctly. In a VeST library, the author would be the one providing the test double for you. If you do not, then implementing a fake only once, by refactoring it continuously with your new understanding of the contract will allow your whole testing codebase to improve under those scenarios.

It’s however very common for you to own the interface, the implementation and the consumer, at which point you’re in the best position to do the right thing, and ship fast in-memory versions of the implementations you expect people to use.

If you don’t, you risk hitting the next issue.

They break encapsulation

An object, in object-oriented development, is by definition encapsulating data and behaviour. Each object is a black box, that you can tell to act, hence the “tell, don’t ask” mantra.

Because an object may use one or many dependencies, building the code by stubbing each method of a dependency as you go along, you implement in your test a lot of knowledge of the inside functioning of your class. This breaks encapsulation, which makes your tests brittle, and refactorings harder.

They introduce extra dependencies

Out of all the issues I’ve already discussed, this is probably the least visible immediately, especially in a world of package managers.

Over time, frameworks and libraries are like fashion, they get in quick and loud, and they get replaced by younger, slimmer next generations, and on and on.

Your test code, just like your applicationcode, suffers from this. The cost of rewriting all test doubles using littered mocking frameworks is high, and you hit the pit of failure. It doesn’t get done. You end up in nonsensical situations, having 4 mocking frameworks in the same library, in code that hasn’t been refactored or touched in years. This code is, for all intent and puproses, dead. And mocking frameworks were probably an accessory to murder.

They lead to auto-mocking containers

This was a thing for a long time, and it is very unfortunate that people still try to do this. The combination of containers, automocking and large dependency trees result in many issues that make code more and more costly to keep.

Large amounts of dependency in a class is a tell-tale sign it’s doing too much. Stop feeding that class new responsabilities and split it.

Large dependency graphs often are because it’s easy to take a dependency, and results in overly-complicated levels of abstractions that serve no purpose. You neither need a repository wrapping a data access class wrapping an actual vendor library, nor do you need 3 levels of logging frameworks talking to one another.

And finally, the encapsulation breakage is worse than with a single class, it now pans out to a whole object tree, making your tests even more brittle. Friends don’t let friends use auto-mocking containers.

They allow for interaction testing too easily

I mention this only for the sake of completeness, because that’s one part of mocking that is not used as much anymore. Interaction testing wants to know how and how often dependencies’ methods are called. This is even more non-sensical than the precedent breakages of encapsulation, you write a class and write a test to verify exactly what the class ends up doing.

Interaction testing has a place, but it’s very small, in a very limited number of scenarios where it’s not possible to test visible effects of the various calls made to a system.


Mocking frameworks are nearly always the wrong choice: they are not a good way to write classes, they lead to the path of brittleness, badly factored code, unwildly class hiearchies, and code duplication.

Do yourself a favour, write in-memory fakes and ship them alongside your code.


Architecture in code

When we build systems, we model the world around us: models, commands, events, resources, they’re all intellectual spectres of reality that help us reason. Yet, most of the code we build tends to focus on implementation. From the code, you would have no way of knowing what models you used.

Messaging is a good example. I’ve been working on distributed messaging systems for eons now, and I see the same implementation over and over again.

// not an actual library
  .Handle(message => new MyHandler().Handle(message));

class MyHandler : IHandle<Event> {
  void Handle(Event) {
    if (Event is Spider)

If you look at this code as-is, you can only know that a thing happens that causes a message to be posted and a “handler” to “handle” said message.

In reality, external stimulii often trigger certain actions from us, which themselves cause other events. An enormous spider next to me may make me jump which may well result into me breaking glasses. I have external stimulii that I know, like spiders crawling, which are events. I have commands, like jumping. I have breaking glasses, which are other events.

Now that explanation makes sense, but the code is not giving you that. The code gives you a very different explanation. The sun, through thermonuclear reaction causes photons to travel at the speed of light all the way through my windows to my sofa, which get scattered by a calcium-based molecular structure, hitting my retina. Through a set of neurons interconnected through electrochemical connections, triggers a flight response, releasing a high dose of adrenaline, causing an automatic muscular response…

The description is now too detailed, and it becomes very hard to know why I broke the glass. It would also become increasingly difficult to explain to you various other reactions that would lead me to break the glass. Without a model, I can’t explain clearly that a divorce and a zombie would also cause me to break glass.

In terms of code, the fact that we focus on the low level of event subscription doesn’t allow us to do anything but what the procedural code dictates, introducing systematic variance, not due to need but due to having no model.

It also prevents us from reflecting on the model. I used to have panic attacks when boarding plane, which for a conference hopper is a rather problematic condition. It’s only once I managed to model my triggers, and model my commands, that I managed to get rid of it. All the same, in code, without a model that can be introspected on, I have no way of reflecting on what my software does, be it that I want to understand it, or like Simon Brown does, document, graph and represent it.

Instead of going for pure messaging, model your messaging patterns to encode in your code what concepts they implement. For example, instead of the IHandle<T>, why not model what you do?

public interface IHandleComponentCommand<T> {
public interface IListenToExternalEvent<T> {

Going one step further, both OpenRasta and FubuMvc used to favour the idea of a configuration model, where all information about your system are pulled into before you actually spin up the system. This allows any further component to have enough information to configure queues, add http handlers, and everything else you may need to spin up the software.

If your model is not rich enough to generate all the plumbing from it, then your model is insufficient to document what your software does. And when you need something that your model can’t cope with, update your model.


Don't version your HTTP APIs

Infoq has released an article covering my talk on “Versioning is evil”, which is awesome. I’m preparing new content for the blog about the subject, and a new version of the talk for later in the year, which will complete and expand on this.

Thanks to all that attended this talk at NDC and!