Moq has been around for quite a few years now (an amazing 4.5 years to be precise). A lot has happened in that time, Moq itself progressed a lot, but more importantly IMHO, there are more choices now, and most of them open source too.
The state of the art for mocking libraries relies for the most part on their syntax, while the inner workings typically remain fairly stable and are similar:
- An internal representation of a fake/mock behavior as specified via the API (a.k.a. “setup”)
- A dynamic proxy generation library (typically Castle DynamicProxy)
- A custom interceptor that upon invocation of the mock at runtime:
- Records calls
- Compares with setup behavior and acts accordingly
That’s pretty much it. The syntax evolves and provides innovative ways on top of this core, and reflects the changing styles and idioms in your programming language of choice.
There is, however, a lot of work that goes into making the resulting behavior user friendly, such as rendering top-notch failure messages, improving debugging and so on. That’s work that layers on top of the core and is very much duplicated in every mocking library implementation. We all seem to be doing the same thing over and over. If I see something really nice in the way (say) NSubstitute renders a failure, I can’t simply leverage that myself, since it’s all tied with its own internal core and is typically a huge work to port over. This hinders evolution and is bad for users. The reason we all make open source is to advance the state of the art, allow others to take ideas, improve on them, or learn from our mistakes. Without the ability to easily port good ideas across libraries, we’re just slowing down everyone for the sake of a little bit of a headstart when we’re the first to come up with a good idea.
Nothing showcases this better than the creator of FakeItEasy himself:
I wanted to see what I could do with the syntax when I had absolutely free hands
Unfortunately, in order for him to have his hands free to play with syntax, he first had to write the entire infrastructure code from scratch, just like me, NSubstitute, Rhino Mocks, and any future author who wants to have his take on mocking syntax and style.
So this got me thinking: wouldn’t it be nice to have a kind of shared mocking sdk which is designed solely for the purpose of supporting arbitrary APIs on top? And if multiple mocking APIs layered on top of it, then we’d all benefit from improvements in the core, such as better platform support, improved error messages, etc.
And with that in mind, I decided that the next revision of Moq (which I assure you has a long and bright future ahead ;)) could not just be a minor polish with a few more new APIs. It had to be the first mocking library to ship an API on top of a completely new and redesigned core SDK that any other mocking libraries could also use.
Hence the Moq Rebirth, now in two parts: Moq SDK and Moq itself.
Beyond Open Source
Now, being open source is a great thing. But not many devs can grab a project’s entire source tree and magically figure our how it works and why. Understanding why certain implementations turned out the way they did, and how the various classes fit together is tough on any non-trivial project.
And deep understanding of the code is precisely what’s needed sometimes to carry forward a project when its owner is no longer around to do it. Or when core features need to be added to keep it alive and fresh with changing requirements.
Therefore, this time I will not develop Moq (Rebirth Edition ;)) in my cave. I will develop it during a series of Google Hangout on Air sessions where anybody can join, ask questions, suggest tests and implementation choices, etc. The entire video sessions will then forever be available on YouTube so that anyone wishing to understand more deeply the project source, or just curious as to how it was built, can have an invaluable (I think) source to do so.
Oh, and I’ll do it following TDD principles as strictly as possible, so it could be educational too, like my older Funq series.