Google mock global mock object memory leak - c++

I am using VS2005, and C++ for unit testing using google mock.
I had a global free function in unit testing, and I used the following code to mock free function:
NiceMock <MockA> mockObj;
struct IFoo {
virtual A* foo() = 0;
virtual ~IFoo() {}
};
struct FooMock : public IFoo {
FooMock() {}
virtual ~FooMock() {}
MOCK_METHOD0(foo, A*());
};
FooMock fooMock;
// foo() implementation
A* foo() {
return fooMock.foo();
}
In the SetUp() function, I set Expectations on the global object like
EXPECT_CALL(fooMock,foo())
.Times(1)
.WillOnce(Return(&mockObj));
TEST(..., instA) {
// ...
}
and in TearDown(), I delete the global mock object fooMock
virtual TearDown(){
delete &fooMock;
}
When I run the code, I get the following error
Error: Memory Leak in xyz.instA,
also,
0 bytes in 0 Free Blocks.
-61 bytes in -1 Normal Blocks.
68 bytes in 7 CRT Blocks.
0 bytes in 0 Ignore Blocks.
0 bytes in 0 Client Blocks.
Largest number used: 11025 byte
Total allocations: 50602 bytes.
Can anyone tell me what is happening here? If I don't delete fooMock, I get the error "fooMock should be delete but never is", or Heap corruption detected.
From the error, I can see that somewhere my heap is being mishandled, but I cannot find the point. I have tried to debug it step by step as well.
Some help would be really great! :)

As Ian stated:
Googlemock/googletest expect the mock to be defined either within the body of the test, or within a test fixture class.
The idea behind it is explained in the Cookbook:
When it's being destroyed, your friendly mock object will automatically verify that all expectations on it have been satisfied, and will generate Google Test failures if not. This is convenient as it leaves you with one less thing to worry about. That is, unless you are not sure if your mock object will be destroyed.
In your case fooMock is a global variable (and as you stated it must stay this way) so after each test you just need to run manual verification:
using ::testing::Mock;
TEST(..., instA)
{
ASSERT_TRUE(
Mock::VerifyAndClearExpectations(
&fooMock));
}
Since it is a global variable you can also just do:
Mock::AllowLeak(&fooMock);
More details in Cookbook - Forcing a Verification and CheatSheet - Verifying and Resetting a Mock:

It looks like the problem is that you're instantiating a global instance of FooMock. Googlemock/googletest expect the mock to be defined either within the body of the test, or within a test fixture class.
In the example above, you'd simply instantiate fooMock inside the test:
TEST(..., instA) {
FooMock fooMock;
// ...
}

So I stumbled upon this question and couldn't figure out a way. But then being a software engineer, I needed to find a solution. So here is what I did.
Suppose you want to mock a Queue. The one function you want to mock is dequeue. I will assume you want to dequeue integers to keep things simple because I want to demonstrate how to make global mocks without memory leaks.
class QueueInterface {
public:
virtual ~QueueInterface() {};
virtual int dequeue() = 0;
};
class QueueMock : public QueueInterface {
public:
virtual ~QueueMock() {};
MOCK_METHOD(int, dequeue, (), (override));
};
// Instead of a global object, have a global pointer
QueueMock *globalQueue;
class TestFixture : public ::testing::Test {
protected:
QueueMock mockedQueue;
void SetUp() {
globalQueue = &mockedQueue; // Point the global pointer to this queue
}
void TearDown() {
globalQueue = NULL;
}
}
// Now you can use this global queue pointer in free function or
// C style functions and override the existing implementations.
// This way you can mock a global object.
int dequeueFromQueue() {
return globalQueue->dequeue();
}
TEST_F(TestFixture, DEQUEUE_TEST) {
// Write your test here to use global queue pointer
// Deref pointer to get mocked object
EXPECT_CALL(*globalQueue, dequeue);
}
In this way, whenever a new test is executed, the member variable mockedQueue is allocated and then deallocated at the end of the test. The globalQueue would point to the member instance of each test every time.
Hope this helps! :)

I ran into the same problem and here is the solution (not sure what exactly happened inside because the global mock obj will be destructed eventually).
std::unique_ptr ptrMockObj(new FooMock ());
At the end of the test case, delete the mock obj ptr
TEST(..., instA)
{
...
ptrMock.Obj.reset()
}

Related

How to test RDMA code without actual hardware?

I have C++ code which makes use of infiniband verbs for RDMA communication. I need to unit test this code, and thus, the function calls related to RDMA such as ibv_get_device_list() need to succeed without any actual hardware. From my understanding, I can do the following:
Create my own definition of each function to return the desired value, and link to this custom definition instead of infinband/verbs.h during testing. - Turning out to be very tedious
Create an interface and provide real and fake implementations of each function. The real one would simply call the infiniband verbs. - Can't do this as it would require too many changes to the original code
Use Soft-RoCE - I need to use the same machine as both the client and server, which I haven't been able to do
Would it be possible to use gmock to mock these functions? What other options can I consider?
Number 2 is the way to go. I'm going to challenge this statement:
Can't do this as it would require too many changes to the original code
If all goes well, your IDE has a "global search and replace" that can be used.
Let's fine the easiest way to abstract out your code with a minimal amount of disruptive changes:
Start by defining a class that simply wraps those C library function calls:
class RDMA
{
public:
virtual struct ibv_device **ibv_get_device_list(int *num_devices)
{
return ::ibv_get_device_list(num_devices);
}
virtual void ibv_free_device_list(struct ibv_device **list)
{
return ::ibv_free_device_list(list);
}
virtual uint64_t ibv_get_device_guid(struct ibv_device *device)
{
return ::ibv_get_device_guid(device);
}
};
Extend the above class with any other related calls you might need.
At global scope, declare an instance of the above class and a pointer to it:
RDMA g_product_code_rdma;
RDMA* g_ptrRMDA = &g_product_code_rdma;
Replace all your product code calls to the ibv functions to call through to the class via the global pointer. That is, change this:
ibv_free_device_list(&list);
to be invoked as:
g_ptrRMDA->ibv_free_device_list(&list);
Alternatively, you could declare helper functions:
ibv_device **global_ibv_get_device_list(int *num_devices)
{
return g_ptrRDMA->ibv_get_device_list(num_devices);
}
And then replace all your calls to use the new "global" version. A simple sed\awk script or just use your IDE to globally search and replace those function calls would be the easiest approach.
At this point, your product code functions the same as before.
in your unit tests, you simply declare a MockRDMA class that inherits from the RDMA class above.
class MockRDMA : public RDMA
{
public:
ibv_device **ibv_get_device_list(int *num_devices) override
{
// return a fake list of devices
}
virtual void ibv_free_device_list(struct ibv_device **list) override
{
return;
}
virtual uint64_t ibv_get_device_guid(struct ibv_device *device) override
{
return 0x012345678;
}
};
Then you just say this at the start of your unit tests:
MockRDMA mock;
g_ptrRDMA = &mock;
Example:
bool test_that_thing()
{
RDMA* original = g_ptrRDMA;
MockRDMA mock;
g_ptrRDMA = &mock;
// test code to validate the code that depends on those RDMA calls
// restore the RDMA class
g_ptrRDMA = original;
return result;
}
If you do decide to go for option 3 (SoftRoCE), it is certainly possible to have the client and server on the same host. You can try a Vagrant box I have created to make it easy to test SoftRoCE in a VM.

How to write a test case which garbage collects in the middle of a function execution?

I have a native class:
class NativeClass
{
int someVariable;
public:
void someNativeFunction(){}
};
I have a managed class, which lightly wraps this native class.
class ManagedClass
{
NativeClass *nativeClassObject;
public:
void someManagedFunction()
{
nativeClassObject->someNativeFunction();
}
};
I use this managed class in my C# application:
static void Main(string[] args)
{
ManagedClass objManagedClass = new ManagedClass();
objManagedClass.someManagedFunction();//line_1
//At this point onwards objManagedClass still has a reference on the stack, but is not used again.
//So, GC can delete this object.
}
Since objManagedClass is not referenced after line_1, garbage collector is free to destroy the object, even if it is processing the internal native call. This will lead to destruction of objManagedClass, which will in turn destroy *nativeClassObject. This is only likely to happen if someNativeFunction is allocating a lot of memory or is taking a long time, but just to be sure, I must add a reference to objManagedClass later after the call.
class ManagedClass
{
NativeClass *nativeClassObject;
public:
void someManagedFunction()
{
nativeClassObject->someNativeFunction();
...
...
System::GC::KeepAlive(this);
}
};
KeepAlive() call should prevent GC from destroying it. Is there any way I can test this scenario? Some test case I could write that would fail if I did not provide KeepAlive(), but would pass once I called it? Would Thread.Sleep(5000) call in between the managed function help?
You can force garbage collection to start by calling GC::Collect and then wait until garbage collection is finished using GC::WaitForPendingFinalizers. This should allow you to test your scenarios.
Take a look at the example on MSDN

Elegant way of overriding default code in test harness

Let's say I have the following class:
class Foo
{
public:
Foo()
{
Bar();
}
private:
Bar(bool aSendPacket = true)
{
if (aSendPacket)
{
// Send packet...
}
}
};
I am writing a test harness which needs to create a Foo object via the factory pattern (i.e. I am not instantiating it directly). I cannot change any of the factory instantiation code as this is in a framework which I don't have access to.
For various reasons I don't want the Bar method to send packets when running it from a test harness.
Assuming I cannot call Bar directly (eliminating potential solutions like using a friend class), what is an elegant design pattern to use to prevent packets being sent out when running my test harness? I definitely don't want to pollute my production code with special cases.
You want Bar to send a packet in ordinary operation, but not in testing. So you will have to have some code which runs when you call Bar during testing, even if it's an empty function. The question is where to put it.
We can't see the code inside the if(aSendPacket) loop, but if it delegates its work to some other class then we can make the substitution there. That is, if the loop is
if(aSendPacket)
{
mPacketHandler.send();
}
so that the work is done by the `packetHandler class:
// packetHandler.cc
void packetHandler::send()
{
// do some things
// send the packet
}
then we can make a "mute" version of the packetHandler class. (Some would call it a stub or a mock class, but there seems to be somedebate about the definitions of these terms.)
// version of packetHandler.cc to be used when testing e.g. Foo
void packetHandler::send()
{
// do some things
// don't actually send the packet
}
When testing Foo, compile this version of packetHandler and link it in. The factory won't know the difference.
If, on the other hand, the code for sending a packet is spelled out in Foo, with no way to head off the behavior outside the Foo class, then you will have to have a "testing" version of Foo.cc (there are other ways but they are clumsy and dangerous), and the best way to do that depends on the details of your codebase. If there are only a couple of "untestable" features like this, then it's probably best to put Foo::bar(...) in a source file by itself, with two versions (and do the same for each of the other special methods). If there are many then may be worth deriving a factory class specific to testing, which will construct instances of, e.g. class testingFoo : public Foo which overrides Bar. After all, this is what the abstract factory design pattern is for.
I would view 'bar' as an algorithm to send data which follows a template method
// Automation Strategies
class AutomationStrategy{
public:
void PreprocessSend(bool &configsend) const {return doPreprocessSend(configsend);}
void PostprocessSend() const {return doPostprocessSend();}
virtual ~AutomationStrategy(){}
private:
virtual void doPreprocessSend(bool &configsend) const = 0;
virtual void doPostprocessSend() const = 0;
};
// Default strategy is 'do nothing'
class Automation1 : public AutomationStrategy{
public:
~Automation1(){}
private:
void doPreprocessSend(bool &configsend) const {}
void doPostprocessSend() const {}
};
// This strategy is 'not to send packets' (OP's intent)
class Automation2 : public AutomationStrategy{
public:
~Automation2(){}
private:
void doPreprocessSend(bool &configsend) const {
configsend = false;
}
void doPostprocessSend() const {}
};
class Foo{
public:
Foo(){
Bar();
}
private:
// Uses Template Method
void Bar(bool aSendPacket = true, AutomationStrategy const &ref = Automation1())
{
ref.PreprocessSend(aSendPacket); // Customizable Step1 of the algorithm
if (aSendPacket) // Customizable Step2 of the algorithm
{
// Send packet...
}
ref.PostprocessSend(); // Customizable Step3 of the algorithm
}
};
int main(){}
If you can't modify 'bar' interface, then configure 'Foo' to accept the test automation strategy in it's constructor and store it (to be later used while calling 'bar')
It might be a gross oversimplification, but my first inclination is to add some sort of testing conditions object (really a variable library) which defaults everything to false, then put hooks in the code where you want to deviate from standard behavior for testing, switching on the [effectively global] testing conditions object variables. You're going to need to do the equivalent logic anyway, and everything else seems either needlessly more complicated, more disruptive to understanding the logic flow inside the object, or more potentially disruptive to the behavior in the testing case. If you can get away with a minimal amount of conditional switch locations/variables, that probably the easiest solution.
My opinion, anyway.

Optional Member Objects

Okay, so you have a load of methods sprinkled around your system's main class. So you do the right thing and refactor by creating a new class and perform move method(s) into a new class. The new class has a single responsibility and all is right with the world again:
class Feature
{
public:
Feature(){};
void doSomething();
void doSomething1();
void doSomething2();
};
So now your original class has a member variable of type object:
Feature _feature;
Which you will call in the main class. Now if you do this many times, you will have many member-objects in your main class.
Now these features may or not be required based on configuration so in a way it's costly having all these objects that may or not be needed.
Can anyone suggest a way of improving this?
EDIT: Based on suggestion to use The Null Object Design Pattern I've come up with this:
An Abstract Class Defining the Interface of the Feature:
class IFeature
{
public:
virtual void doSomething()=0;
virtual void doSomething1()=0;
virtual void doSomething2()=0;
virtual ~IFeature(){}
};
I then define two classes which implement the interface, one real implementation and one Null Object:
class RealFeature:public IFeature
{
public:
RealFeature(){};
void doSomething(){std::cout<<"RealFeature doSomething()"<<std::endl;}
void doSomething1(){std::cout<<"RealFeature doSomething()"<<std::endl;}
void doSomething2(){std::cout<<"RealFeature doSomething()"<<std::endl;}
};
class NullFeature:public IFeature
{
public:
NullFeature(){};
void doSomething(){std::cout<<"NULL doSomething()"<<std::endl;};
void doSomething1(){std::cout<<"NULL doSomething1()"<<std::endl;};
void doSomething2(){std::cout<<"NULL doSomething2()"<<std::endl;};
};
I then define a Proxy class which will delegate to either the real object or the null object depending on configuration:
class Feature:public IFeature
{
public:
Feature();
~Feature();
void doSomething();
void doSomething1();
void doSomething2();
private:
std::auto_ptr<IFeature> _feature;
};
Implementation:
Feature::Feature()
{
std::cout<<"Feature() CTOR"<<std::endl;
if(configuration::isEnabled() )
{
_feature = auto_ptr<IFeature>( new RealFeature() );
}
else
{
_feature = auto_ptr<IFeature>( new NullFeature() );
}
}
void Feature::doSomething()
{
_feature->doSomething();
}
//And so one for each of the implementation methods
I then use the proxy class in my main class (or wherever it's required):
Feature _feature;
_feature.doSomething();
If a feature is missing and the correct thing to do is ignore that fact and do nothing, you can get rid of your checks by using the Null Object pattern:
class MainThing {
IFeature _feature;
void DoStuff() {
_feature.Method1();
_feature.Method2();
}
interface IFeature {
void Method1();
void Method2();
}
class SomeFeature { /* ... */ }
class NullFeature {
void Method1() { /* do nothing */ }
void Method2() { /* do nothing */ }
}
Now, in MainThing, if the optional feature isn't there, you give it a reference to a NullFeature instead of an actual null reference. That way, MainThing can always safely assume that _feature isn't null.
An auto_ptr by itself won't buy you much. But having a pointer to an object that you lazily load only when and if you need it might. Something like:
class Foo {
private:
Feature* _feature;
public:
Foo() : _feature(NULL) {}
Feature* getFeature() {
if (! _feature) {
_feature = new Feature();
}
return _feature;
}
};
Now you can wrap that Feature* in a smart pointer if you want help with the memory management. But the key isn't in the memory management, it's the lazy creation. The advantage to this instead of selectively configuring what you want to go create during startup is that you don't have to configure – you simply pay as you go. Sometimes that's all you need.
Note that a downside to this particular implementation is that the creation now takes place the first time the client invokes what they think is just a getter. If creation of the object is time-consuming, this could be a bit of a shock to, or even a problem for, to your client. It also makes the getter non-const, which could also be a problem. Finally, it assumes you have everything you need to create the object on demand, which could be a problem for objects that are tricky to construct.
There is one moment in your problem description, that actually would lead to failure. You shouldn't "just return" if your feature is unavailable, you should check the availability of your feature before calling it!
Try designing that main class using different approach. Think of having some abstract descriptor of your class called FeatureMap or something like that, which actually stores available features for current class.
When you implement your FeatureMap everything goes plain and simple. Just ensure (before calling), that your class has this feature and only then call it. If you face a situation when an unsupported feature is being called, throw an exception.
Also to mention, this feature-lookup routine should be fast (I guess so) and won't impact your performance.
I'm not sure if I'm answering directly to your question (because I don't have any ideas about your problem domain and, well, better solutions are always domain-specific), but hope this will make you think in the right way.
Regarding your edit on the Null Object Pattern: If you already have a public interface / private implementation for a feature, it makes no sense to also create a null implementation, as the public interface can be your null implementation with no problems whatsoever).
Concretely, you can have:
class FeatureImpl
{
public:
void doSomething() { /*real work here*/ }
};
class Feature
{
class FeatureImpl * _impl;
public:
Feature() : _impl(0) {}
void doSomething()
{
if(_impl)
_impl->doSomething();
// else case ... here's your null object implementation :)
}
// code to (optionally) initialize the implementation left out due to laziness
};
This code only benefits from a NULL implementation if it is performance-critical (and even then, the cost of an if(_impl) is in most cases negligible).

Mocking using boost::shared_ptr and AMOP

I'm trying to write mocks using amop. I'm using Visual Studio 2008.
I have this interface class:
struct Interface {
virtual void Activate() = 0;
};
and this other class which receives pointers to this Interface, like this:
struct UserOfInterface {
void execute(Interface* iface) {
iface->Activate();
}
};
So I try to write some testing code like this:
amop::TMockObject<Interface> mock;
mock.Method(&Interface::Activate).Count(1);
UserOfInterface user;
user.execute((Interface*)mock);
mock.Verifiy();
It works! So far so good, but what I really want is a boost::shared_ptr in the execute() method, so I write this:
struct UserOfInterface {
void execute(boost::shared_ptr<Interface> iface) {
iface->Activate();
}
};
How should the test code be now? I tried some things, like:
amop::TMockObject<Interface> mock;
mock.Method(&Interface::Activate).Count(1);
UserOfInterface user;
boost::shared_ptr<Interface> mockAsPtr((Interface*)mock);
user.execute(mockAsPtr);
mock.Verifiy();
It compiles, but obviously crashes, since at the end of the scope the variable 'mock' gets double destroyed (because of the stack variable 'mock' and the shared_ptr).
I also tried to create the 'mock' variable on the heap:
amop::TMockObject<Interface>* mock(new amop::TMockObject<Interface>);
mock->Method(&Interface::Activate).Count(1);
UserOfInterface user;
boost::shared_ptr<Interface> mockAsPtr((Interface*)*mock);
user.execute(mockAsPtr);
mock->Verifiy();
But it doesn't work, somehow it enters an infinite loop, before I had a problem with boost not finding the destructor for the mocked object when the shared_ptr tried to delete the object.
Has anyone used amop with boost::shared_ptr successfully?
You may want to try using a more explicit cast. I'm not sure if this will work, but give it a try.
// Get the mock generator
boost::shared_ptr< amop::TMockObject<Interface> > mock
= boost::make_shared< amop::TMockObject<Interface> >;
// Get the mocked interface
boost::shared_ptr<Interface> imock = boost::dynamic_pointer_cast<Interface>(mock);
// Setup mock usage expectations
mock->Method(&Interface::Activate).Count(1);
// Run the test
UserOfInterface user;
user.execute(imock);
// Verify the expectations were met
mock->Verifiy();
Well, I never used amop, but perhaps this boost pattern will help..
To create a boost shared_ptr you can also use
boost::shared_ptr<Interface> mock(new amop::TMockObject<Interface>());
This way the mock object is not created on the stack and only destroyed if the reference counter in the shared_ptr gets to zero.
Because this is essentially the same as your second try, another tip:
If you encounter problems that look like c++ is not finding the right destructor, you might introduces a virtual destructor in the base (interface) class. Does amop allow this?
class Interface{
virtual ~Interface() { }
...
};
You can give the shared_ptr a custom functor that will be called instead of delete when the reference count goes to zero.
The code then will look like this (I didn't try to compile it):
struct NoOpDel
{
void operator() (void *) { }
}
amop::TMockObject<Interface> mock;
mock.Method(&Interface::Activate).Count(1);
UserOfInterface user;
boost::shared_ptr<Interface> imock((Interface*)mock, NoOpDel())
user.execute(imock);
mock.Verify();
See Boost API doc for more details, you are interested in this constructor:
template<class Y, class D> shared_ptr(Y * p, D d);
Disclaimer: I'm the author of HippoMocks
Using HippoMocks you can specify that you expect the destructor is called at the end of your test. It also implicitly validates your expectations at the end of your test. That way it can even guard against a stray shared_ptr on the heap that you forgot to delete or a class that doesn't take ownership or forgets to delete the pointer in the case that you don't use a shared_ptr.
There is a way to use shared_ptr with amop
struct Interface {
virtual ~Interface() {}
virtual void Activate() = 0;
};
TEST(MockObjectMethodDestructor)
{
TMockObject<Interface> mock;
mock.Method(Destructor());
boost::shared_ptr<Interface> ptr((IInterface*)mock);
ptr.reset();
}