It is customary to wish people a happy new year, to take on new year’s resolutions, and generally to celebrate the upcoming unknown. Rather than do this, I’d like to take a second, for we have an extra one in 2016, to look back on 2016, and thank all the people that have made it what it was: a year I’ll remember with fondness.

This year has been the best in a long time. I’ve relaunched this website, spoke at conferences in many countries on two continents, met hundreds of you, restarted work on both OpenRasta and “the book”, albeit not as much as I’d have liked, launched the httpapis.com chat room, worked with great clients and even greater people, laughed, cried and generally lived. There were a few downs, some friendships disappeared, some people upset unintentionally, some projects didn’t happen, and on my path of self discovery, some cuts and life changes had to be made. So is life, up and downs often feed one another. I wouldn’t have had any of the great times without an amazing group of people around me, and for once I’d like to tell them how much it all means to me. I may edit the post as I remember more names, I do apologise to anyone I forgot, it’s probably only temporary!

Thank you to my family, for having me, being there, inviting me to share your happy and your less happy moments. I’m very glad and very lucky to have such a fulfilling environment. A special thank you to mom, for being there through everything over the past 35 years, such endurance! Than you to Dominique, for making LA peaceful for me; Thank you Nana for organising a surprise birthday dinner, first one I ever had. Thank you to all the others, I love you all, you know who you are.

Thank you to my friends, old and new. Jon and Simon, always there in my life. We’re ageing rather well, and I hope we continue Friday nights for many years to come. Thank you to my favourite BA, Rossana, I’m so glad to see you grow year on year, your strength and determination is a lesson to us all. Thank you to Marion, Pierre, Marie, Christina and Alessandro, for all the good moments we have in Monaco; Colin and Paul, ever present, kindest spirits, Scotland feels at home thanks to you; Didier, you made it in Barcelona, thanks for a great night; Richard, I don’t see enough of you, but you’re with me on all my easyjet flights nevertheless.

I can’t not mention all the geeks I have spent such a good time with, and I am very privileged to call friends: Toby, for being the best maintainer of OpenRasta since ever; Ian for making sure hugs go around, people and repositories alike; Liam without which cheese wouldn’t have the same appeal; Dylan, a rock I have had the privilege of hanging on many times; Ben and Barbara, so many dinners, good times and swimming pool moments, one of you get a ring on it already; Barry and Nikky for being the best hosts in Seattle, the seafood buttered orgy memories will stay with me forever; Glenn, for the great times in Portland, our conversations, and your enormous kindness; Chris and Joao, I wouldn’t enjoy lunches without you, and your work to promote diversity is so badly needed in our industry; Adam, Vancouver wouldn’t be the same without you, and no I won’t switch to Linux in 2017, maybe the year after :-P; Jef, those selfies turned out pretty great, and thank you for making me discover the wonders of Caesar cocktails, they’re pretty awesome.

You spend a lot of time with clients, and I’ve been very lucky to work alongside pretty awesome people: Dave, welcome to adulthood; Nigel and Chris, Brighton was such a fun time, just what I needed to start the year on a high note; Allan, Simon, Atif, Matt, Aaron, Sam and the others, you make that office fun to be in, here’s hoping I spend more time there.

Conferences have been amazing this year, and it wouldn’t happen without organisers sweating their arse off for months to enable us a platform for sharing knowledge. I can’t mention you all, it takes a village, but a few special mentions are in order, in no particular order: Jakob, you make NDC great, and that beach day and dinner was awesome, we should do more of that; Iva for making Las Vegas happen; Dominika and the whole crew at get.net, your dedication and support went well beyond the call of duty, thank you for everything you did; Andreas for tirelessly giving me more speaking space at Oredev, I had such fun in no small parts thanks to you; Anna and Yann, for being the most organised and efficient planners I’ve ever met, and even better skiers, thanks for the opportunity to discover Whistler and Vancouver; Todd for making conferences in pubs possible, I can’t believe you managed to haggle that jumper from that waitress, this is tons of awesome.

Sickness is part of life, and this year has been very tough on the people around me. I’ve done the dryathlon in September, and collected a bit of money for cancer research, because I think of you all often: Laurie, Violaine, Morten, Patrick, Steven and Anthony, your strength of character is enlightening. To those that didn’t pull through, thank you for having been in my life: Mark, I will never look at a Guinness without thinking of you, you would have loved your send off so much; Pieter, you loved your send off, and I’ll always be grateful for your guidance, late night skype sessions, and your guide to psychopaths, I was brought out of the darkness in part thanks to your vision.

Thank you to the people of the two slacks I always stay on, ddd-cqrs-es and httpapis, your insights are humbling, and banter refreshing: Damian, Dan, Joao, Adam Ralph, James G, Mike Amundsen, and all the others. And for those that were in my life and no longer are, I wish you all the best in your endeavours, let your future be bright and your life full of love and happiness.

Happy old year to one and all.

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.

Conclusion

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.

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
MyAwesomeQueueSystem
  .ListenOn(MyFabTopicNameBuilder("home"))
  .IntoQueue("reaction")
  .Handle(message => new MyHandler().Handle(message));

class MyHandler : IHandle<Event> {
  void Handle(Event) {
    if (Event is Spider)
      me.Jump();
  }
}

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.