mimic++ v4
|
The core aspect of the library. More...
Topics | |
interfaces | |
Contains utility to simplify interface mocking. | |
Classes | |
class | mimicpp::Mock< FirstSignature, OtherSignatures > |
A Mock type, which fully supports overload sets. More... | |
Macros | |
#define | MIMICPP_SCOPED_EXPECTATION MIMICPP_DETAIL_SCOPED_EXPECTATION_IMPL(__COUNTER__) |
Convenience macro, which creates a ScopedExpectation with a unique name. | |
#define | SCOPED_EXP MIMICPP_SCOPED_EXPECTATION |
Shorthand variant of MIMICPP_SCOPED_EXPECTATION. | |
The core aspect of the library.
Mocks are responsible for providing a convenient interface to set up expectations and handle received calls. At a basic level users can specify arbitrary overload sets, which the mock shall provide and for which expectations can be defined.
Mocks themselves can be used as public members and can therefore serve as member function mocks. Have a look at the following example, which demonstrates how one is able to test a custom stack container adapter (like std::stack
) by utilizing mocking.
At first, we define a simple concept, which our mock must satisfy.
The implemented must be test-able for emptiness, must have a push_back
and pop_back
function and must provide access to the last element (both, const and non-const).
The MyStack
implementation is rather simple. It provides a pair of pop
and push
functions and exposes the top element; as const or non-const reference. pop
and both top
overloads test whether the inner container is empty and throw conditionally.
To make the test simpler, let's fixate T
as int
. A conforming mock then must provide 5 member functions:
bool empty() const
,void push_back(int)
,void pop_back()
,int& back()
andconst int& back() const
. back
).Eventually we are able to formulate our tests. The test for push
is rather straight-forward.
We create our container mock, setting up the expectation and moving it into the actual stack. The move is required, because MyStack
doesn't expose the inner container. There are more advanced solutions for that kind of design, but that would be out of scope of this example.
The pop()
test is also quite simple, but we should definitely test, that pop
never tries to remove an element from an empty container.
As you can see, the success test sets up two distinct expectations; They may be satisfied in any order, even if only one order here semantically makes sense. We could use a sequence
object here instead, but with the second test (the empty case) we already have enough confidence.
The empty test then just creates a single expectation, but in fact it also implicitly tests, that the pop_back
of the container is never called.
Finally, we should test both of the top()
functions.
In the first section we check both overloads, when no elements are present.
The second section then tests when the container is not empty.
#define MIMICPP_SCOPED_EXPECTATION MIMICPP_DETAIL_SCOPED_EXPECTATION_IMPL(__COUNTER__) |
Convenience macro, which creates a ScopedExpectation with a unique name.
#define SCOPED_EXP MIMICPP_SCOPED_EXPECTATION |
Shorthand variant of MIMICPP_SCOPED_EXPECTATION.