Peter Bindels wrote:
Hi all,
Over the past three-quarters of a year I've been working (with three friends) on a mocking framework for C++. In our vision, it would be a good complement to Boost.Test for testing classes separate from interfaces required - it would improve the ability to unit-test the classes that tie others together and that implement higher-level algorithms.
Can you please give specific usage examples you have in mind.
It does this by creating an object that is "derived" from a given class at runtime, and replacing the functions with functions that redirect to
What if I want to mock some concepts instead of interfaces?
verifying logic. The verifying logic uses basic structures to record expectations and to verify they happened. These ways of creating an object at runtime and modifying it are highly compiler dependant but remarkably portable - as it runs on at least 3 different compiler series (GCC, MSVC, EDG-based) and 5 platforms (Windows XP, Windows CE, Linux, QNX, bare platform), with few modifications.
Can you show an example of how much effort is required mock something up?
The library has been released under the name "Hippo Mocks" already. I'm interested in submitting it to Boost for three reasons. First of all, I believe that there may be obvious or very interesting optimizations or expansions I do not notice. Second, as Christian has elaborated on already, having the Boost tag on the project makes it more noticed and more used. As it has taken quite a bit of time from me already I would like people to use it. Third, Boost.Test allows testing code but does not support mocking. In the environment of unit testing, anything that is not a base library benefits from mocking by abstracting away details that are irrelevant and that will break your test unnecessarily.
Boost.Test does have some support for interaction based testing already. Including class mock_object <boost/test/mock_object.hpp>. That said I'd be happy to offload this part and support your efforts. I'd like to know though: 1. How does your solution compares with what I have in this header? 2. How you solution compares to google mock library? 3. Did you see BoostCon presentation about mocks? How does your solution compares? 4. Will your solution support interaction-based testing facilities inside the Boost.Test (exception safety testing, tests for logged interaction expectations)?
For Boost the main changes would be superficial in the naming and in using more default libraries instead of a new implementation. For Hippo Mocks I've decided to make no assumptions in anything over C++98 so there's a full Tuple implementation and so on.
Why not use boost?
If there's an interest I'll spend the evening porting the code to qualify for the Boost coding norms and upload it to the vault (if I can - but that should be OK). I would like you to take a look at the code and tell me what you think of it.
There is definite interest on my part to move further interaction based testing support and full featured mocks. Please upload your code and I can try to comment on it when I have time. Gennadiy