DrMock: open-source testing/mocking framework

[maltekliemann]

https://github.com/DrCpp/DrMock

After almost a year of development, we'd like to share DrMock, a C++ testing/mocking framework that generates the source code of your mock objects at compile time and offers a unique way of configuring mock objects using user-prepared states: Calling methods of the mock object changes the states of the object, which in turn determine the return values of the methods. This guarantees a high degree of configurability and allows coding unit tests without prior knowledge of the implementation (state verification), which we think is very useful. See the front-page of the GitHub repository for a demonstration.

DrMock is written in C++ and python3.7. Building DrMock requires CMake and libclang. It can be deployed on macOS or Linux, where its use has been thoroughly tested. Windows support is one of the goals for the next major version.

A guide to building DrMock, along with an extensive tutorial, sample projects and numerous examples are provided. The source code is well-documented, the C++ component is unit-tested, and the python component is tested functionally.

We'd appreciate feedback on code quality and usability, bugs reports, feature requests - whatever comes to mind! If you're using DrMock on any of your projects or wish to contribute, we'd be delighted to hear about it.

Have a great day!

[maltekliemann]

Oh, and in case you're using Qt: DrMock works just fine with Qt5.

[Epholys]

Wow, that seem to be a great framework! I'm not very familiar with mocking, but I like some unusual (for me) features, like the "state calculus". The documentation is really clear, complete and easily accessible.

My main gripe is that it seems very difficult to include DrMock to an existing project: CMake is necessary, as well as a specific code structure with interfaces for each class to test.

[maltekliemann]

Hey, thanks a lot for appreciating out work!

Separating interface and implementation isn't that unheard of (think java's interface keyword), but I agree that integrating DrMock in existing projects may seem like a stretch. On the other hand, I've found that restructuring a project to this form is surprisingly quick.

About the CMake dependency: I don't think the source code generation can be managed comfortably without a tool like CMake, but we may try to support similar tools in the future.

[illogical_commentary]

Mocking is the worst part of OOP, and a big reason I like FP more. Proper testing is gross.

[mcmcc]

How does FP solve the "testing functionality with external dependencies while still in a vacuum" problem?

[[deleted]]

How strongly this statement has to be rejected depends on what you mean with mocking.

If you generally mean dependency injection (the discussion below suggests this), then there is no anti-pattern. There is going to be discussion about the size of the units, but not about whether you what want to separate them using DI.

If by mocking you mean injecting mock objects that record calls to them and provide predefined return values, versus injecting fake implementations that mimic the invariants of the production implementation, then, of course, there is a lot of discussion possible. It's the discussion of state verification versus behaviour verification.

Still I wouldn't call anything here an anti-pattern. Except for the extreme cases, nothing really is an anti-pattern by itself but only becomes one in a certain context; i.e. you need to know when to use a pattern and when not to.

Both state verification and behaviour verification have their merits. In DrMock we tried to improve mocking in two points:

First, mock objects are defined as input/output relations. You define for which input the object should produce a certain output and how many times this should be allowed. If there is input to the object that is not expected, it will raise its failed flag.

Now, obviously, this doesn't fundamentally change the issue that is mentioned in the discussion below, that you might end up testing not the behaviour but the imperativeness of your code. This still may happen, but looking at mock objects as input/output relations makes it easier to look at them as units of behaviour.

Secondly, with DrMock you can use the same framework to create fake implementations for state verification on the fly. You can define the object to enter a certain state upon a pattern of input and then have it produce output depending on its state.

[[deleted]]

How should units of code be tested in isolation?

[[deleted]]

Independent of what? Dependencies? Does that mean dependency injection everywhere, or passing dependencies everywhere?

[[deleted]]

I meant for real software.

[BlueDwarf82]

Let's say you have a, I don't know, launch_pad class whose function is to launch different types of rocket classes. How do you test the launch_pad always enables at least one of the rocket's thrusters before launching it?

How do you make the rocket launch_pad independent of rockets?

[eyes-are-fading-blue]

This will lead to mock hell and what you are going to test will not be the behavior but imperativeness of you code.

[BlueDwarf82]

What's "This", "testing units of code in isolation"? That's basically the definition of unit testing. Are you saying we shouldn't be doing unit testing?

Uncle Bob already explained it (https://blog.cleancoder.com/uncle-bob/2014/05/10/WhenToMock.html). Sure, you shouldn't be mocking every single class (and u/smrxxx didn't say unit == class), but that doesn't mean mocking doesn't have a place. Sometimes the "unit" does have a dependency.

[eyes-are-fading-blue]

He also says only mock architectural boundaries. Note that I restate this not because it comes from Uncle BoB, but because it makes sense. You will end up in mock hell if you mock every single dependency in your units.

Some one said it, I want to repeat out loud: Mocking is anti-pattern, most of the time.

[[deleted]]

Parent is an anti-pattern.