Google-Mock an already declared method - c++

The syntax of MOCK_METHOD can be used inside a class definition:
class A {
MOCK_METHOD0(f, void(void));
};
Is it possible to mock a method that has already been declared? What I want is to do something similar to:
#include "gmock/gmock.h"
class HelloTest {
void f();
};
MOCK_METHOD0(HelloTest::f, void(void));
The idea is to put the class definition in an hpp file and then the mocks in a cpp file. In effect, my class definition with its methods' prototypes needs to be in common with other cpp files in my build chain and I don't want to use virtual functions.
Unfortunately, when I try to do what I wrote above, I get the following error on the line that contains MOCK_METHOD0:
error: ‘gmock0_HelloTest’ has not been declared
What does this error mean and is there a way to do what I want?

To begin with, your MOCK_METHOD0() declaration must belong to a mock class, under a public section. For instance, your code snippet:
#include "gmock/gmock.h"
class HelloTest {
void f();
};
MOCK_METHOD0(HelloTest::f, void(void));
Should instead look like this:
#include "gmock/gmock.h"
class HelloTest {
virtual void f();
};
class Mock_HelloTest : public HelloTest {
public:
MOCK_METHOD0(f, void(void));
};
Now, you'll notice that I've changed f() to be virtual instead, since your use of HelloTest::f in MOCK_METHOD0 requires f() to be virtual.
Since you don't want to use virtual functions, your only other option is to use what the Google Mock team calls hi-perf dependency injection. With this non-virtual approach, you'd have to create a separate mock class that doesn't inherit from HelloTest. You'd also need to templatize any code that currently uses HelloTest to switch between HelloTest in production and Mock_HelloTest in tests.
As an example, let's say you have the following function that calls HelloTest::f():
void RunHelloTest() {
HelloTest HT;
HT.f();
}
You would set up your code snippet as follows:
#include "gmock/gmock.h"
class HelloTest {
void f(); // <- f is no longer virtual
};
class Mock_HelloTest { // <- Mock_HelloTest no longer inherits from HelloTest
public:
MOCK_METHOD0(f, void(void));
};
And modify RunHelloTest() to accept a template type argument:
template <class HelloTestClass>
void RunHelloTest() {
HelloTestClass HT;
HT.f(); // <- will call HelloTest::f() or Mock_HelloTest::f()
}
With this setup, you'd call RunHelloTest<HelloTest>() in your production code, and RunHelloTest<Mock_HelloTest>() in your test code.

Related

Injecting a Mock using registerConstructor

I've successfully set up a Mock for injection via fruit using .replace(get*Component).with(getMock*Component) like so:
#include <gmock/gmock.h>
#include "mockBar.h"
#include "classUnderTest.h"
namespace foo {
fruit::Component<ClassUnderTest, MockBar> getMainComponent()
{
return fruit::createComponent()
.replace(getBarComponent)
.with(getMockBarComponent)
.install(getClassUnderTestComponent);
}
class ClassUnderTestTest : public ::Testing::Test
{
protected:
fruit::Injector<ClassUnderTest, MockBar> injector{getMainComponent};
MockBar *mockBar{injector};
ClassUnderTest *classUnderTest{injector};
};
// TEST_F declarations
}
For the base mock as I'm writing that myself I have no problems because I can utilise the INJECT() macro on the default constructor and bind the mock to the interface in getMock*Component like so:
#include "bar.h"
namespace foo
{
class MockBar : public Bar
{
public:
INJECT(MockBar()) = default;
// MOCK_METHOD declarations
};
fruit::Component<Bar> getMockBarComponent()
{
return fruit::createComponent()
.bind<Bar, MockBar>();
}
}
For a StrictMock where the constructor is defined in the googlemock library as I understand things I should be using .registerConstructor<StrictMock<Mock*>()>() instead and this is where my problems start.
No explicit binding nor C::Inject definition was found for T.
For the sake of troubleshooting I've removed the INJECT() macro and applied this logic to the base mock like so which gives me the same error when trying to build:
#include "bar.h"
namespace foo
{
class MockBar : public Bar
{
public:
// MOCK_METHOD declarations
};
fruit::Component<Bar> getMockBarComponent()
{
return fruit::createComponent()
.registerConstructor<MockBar()>()
.bind<Bar, MockBar>();
}
}
Tried with registerProvider() like so for the sake of argument but got the same error:
fruit::Component<Bar> getMockBarComponent()
{
return fruit::createComponent()
.registerProvider([](){ return new MockBar; })
.bind<Bar, MockBar>();
}
registerFactory<Mock*()>() would appear to be excessive for what I'm trying to do (I only need the one instance) so I've not tried delving into that.
My presumption because I'm new to both googlemock and fruit and because my C++ experience isn't stellar is there's a nuance I'm missing here regardless of what I've read to the contrary.
Any ideas/suggestions for what I should try next or blaringly obvious errors I've made?
I can abstract out some more of my code if I haven't captured everything of importance here.
Ta in advance!

C++ combining namespaces

I have some shared files that I want to use between two programs A and B that have the same compile target and are very identical.
So, I tried to separate them into two namespaces and create a shared namespace for the shared files
Interfaces.h
namespace ns_s {
class SomeClass;
class IFoo {
virtual void bar(SomeClass*) = 0;
};
}
SomeHeaderinA.h
#include "Interfaces.h"
namespace ns_a {
using namespace ns_s;
class Foo : public IFoo {
virtual void bar(SomeClass* p) override { ... }
};
}
However the compiler is complaining now that my member function bar does not override anything, so it seems to not see the interface implementation.
Why is that the case? And why does the compiler not already complain about a missing class IFoo?
EDIT:
Looks like I missed an essential part that contributes to the problem. I pre-declared a class that is a parameter of the interface method. Now that I ahve a pre-declaration in namespace shared and an actual declaration in namsepace A those things are not the same anymore.
Is there a good way to fix this? Only a small subset of interfaces have arguments that are defined in one or the other namesapce (A or B), so I could leave different implementations in each of them, but it would be nice to have it all in the shared space if possible in a clean fashion.
Here is a link
http://coliru.stacked-crooked.com/a/79fa58e50e7b8637
Problem
As shown in the linked code, the problem is caused by SomeClass.
The line
class SomeClass{};
declares and defines SomeClass in namespace ns_a. It does not define SomeClass in namespace ns_s.
The declaration of class ns_s::IFoo::bar uses ns_s::SomeClass.
The declaration of class ns_a::IFoo::bar uses ns_a::SomeClass.
That's the override is an error.
Solution
You can fix it by:
Removing the definition of SomeClass from ns_a, or
Using ns_s::SomeClass in the declaration of ns_a::IFoo::bar.
namespace ns_a {
using namespace ns_s;
class Foo : public IFoo {
virtual void bar(SomeClass* p) override {}
};
}
or
namespace ns_a {
using namespace ns_s;
class SomeClass{};
class Foo : public IFoo {
virtual void bar(ns_s::SomeClass* p) override {}
};
}

Accessing protected variable in googletest

I have this class testC that is meant for google testing
class testC : public A { };
and then bunch of TEST's that are in the same file.
TEST(test_case_name, test_name) {
... test body ...
}
A is structured like this
class A{
protected:
B b;
public:
//constructors
//destructor
//member functions
Q: How can I access b in all the TEST(){} functions through testC?
I tried to do a getter in testC
public:
testC getTest(){
testC test;
return test;
}
and i also tried with returning a reference, but no luck...
Try the FRIEND_TEST macro provided by googletest. Have a look in the advanced guide under Private class members.
You have to declare the test as a friend of the code under test. If I'm not mistaken you have to declare the friendship for all tests that want to access protected members.
class MySystemUnderTest
{
#ifdef _MY_UNIT_TEST
FRIEND_TEST(MySystemUnderTest_test, functionA_prereq_expected);
FRIEND_TEST(MySystemUnderTest_test, functionB_prereq_expected);
#endif
...
};
In the example above I use the preprocessor symbol _MY_UNIT_TEST to remove the declaration from productive code. The methods functionA_prereq_expected and functionB_prereq_expected would be defined in the test fixture MySystemUnderTest_test.
You have to add the FRIEND_TEST declaration in the code under test. That's the price you have to pay if you want to test against protected / private members.
Instead of adding the FRIEND_TEST directly into the class to be tested ClassToTest surrounded by an #ifdef statement (as suggested by the post by anhoppe) for protected members and methods I would create another class test::ClassToTest which inherits from the class to be tested and registers the test suite and the tests as friends as follows:
Inside file implementation.hpp:
namespace some {
namespace complicated {
namespace ns {
// Class that we want to test
class ClassToTest {
public:
constexpr ClassToTest() noexcept
: member_to_be_accessed{7} {
return;
}
protected:
// The protected member (or method) to be accessed
int member_to_be_accessed;
};
}
}
}
Inside the file test.hpp:
#include <gtest/gtest.h>
#include "implementation.hpp"
namespace test {
// The derived class that registers the test fixture and tests as friends
class ClassToTest : public some::complicated::ns::ClassToTest {
using some::complicated::ns::ClassToTest::ClassToTest;
friend class SomeTestFixture;
FRIEND_TEST(SomeTestFixture, someTest);
};
// The test fixture
class SomeTestFixture : public testing::Test {
protected:
SomeTestFixture() noexcept
: class_to_test{} {
return;
}
ClassToTest class_to_test;
};
// A test
TEST_F(SomeTestFixture, someTest) {
EXPECT_EQ(class_to_test.member_to_be_accessed, 7);
}
}
The advantage of this is that you clearly separate the test from the implementation and that you can get around the restriction regarding namespaces:
If the class is defined in a namespace, then in order to be friends of
the class, test fixtures and tests must be defined in the exact same
namespace, without inline or anonymous namespaces.
Furthermore, as pointed out in "Testing Private Code" section of the "Advanced GoogleTest Guide" generally the black-box approach should be used: Code should be tested through its public interface only. If you can, re-structure your code separating the interface from the implementation using the Pointer to Implementation (PImpl) design strategy and test the internals independently.

Hiding includes parent library

I am writing a shared library (call it MyLib) which depends on another library (call it ParentLib). The ParentLib has a few virtual functions which I am implementing in MyLib along with several other independent implementations.
// MyLib.h
#include <parentlib_library.h>
class Foo : public ClassinParent
{
public:
void DefinitionofParentLibFunction();
private:
// ...
};
I was able to compile and generate the MyLib with no issues but when the MyLib is used by the application, I need to include the ParentLib_library.h to compile the code.
One of my requirements is that the ParentLib should be completely hidden from the application. I am not sure of the next step to achieve this.
Any ideas?
If your declaration used in callback or implementation of interface from 3dparty lib - then no way. In all another cases I usually apply following 3 approaches.
1) Use aggregation. Declare ClassInParent as forward and use as member of Foo:
class ClassInParent;//forward declare
class Foo
{
ClassInParent* _inst; //use either pointer of reference to external
public:
void method_of_ClassInParent() //make facade for parent methods if needed
}
2) Separate your class into interface (that is not depended on ClassInParent) and implementation (that is not expose via #include)
Your Foo.h:
class Foo
{
public:
virtual void do_smth() = 0;
};
Your Foo.cpp:
#include <parentlib_library.h>
class FooImpl : public Foo, public ClassInParent
{
void do_smth()
{//implementation
3) Use templates. Instead of explicit inherience use template:
template <class T>
class Foo : public T
{
Later in your code Foo<ClassInParent>

How can I test private members and methods of classes?

I am trying to do unit testing (using the Boost unit testing framework) on a C++ class called VariableImpl. Here are the details.
class Variable
{
public:
void UpdateStatistics (void) {
// compute mean based on m_val and update m_mean;
OtherClass::SendData (m_mean);
m_val.clear ();
}
virtual void RecordData (double) = 0;
protected:
std::vector<double> m_val;
private:
double m_mean;
};
class VariableImpl : public Variable
{
public:
virtual void RecordData (double d) {
// Put data in m_val
}
};
How can I check that the mean is computed correctly? Note that 1) m_mean is protected and 2) UpdateStatistics calls a method of another class and then clears the vector.
The only way I can see would be to add a getter (for instance, GetMean), but I don't like this solution at all, nor I think it is the most elegant.
How should I do?
And what should I do if I were to test a private method instead of a private variable?
Well, unit testing should test units and ideally every class is a self-contained unit – this follows directly from the single responsibility principle.
So testing private members of a class shouldn’t be necessary – the class is a black box that can be covered in a unit test as-is.
On the other hand, this isn’t always true, and sometimes with good reasons (for instance, several methods of the class could rely on a private utility function that should be tested). One very simple, very crufty but ultimately successful solution is to put the following into your unit-test file, before including the header that defines your class:
#define private public
Of course, this destroys encapsulation and is evil. But for testing, it serves the purpose.
For a protected method/variable, inherit a Test class from the class and do your testing.
For a private, introduce a friend class. It isn't the best of solutions, but it can do the work for you.
Or this hack:
#define private public
In general, I agree with what others have said on here - only the public interface should be unit tested.
Nevertheless, I've just had a case where I had to call a protected method first, to prepare for a specific test case. I first tried the #define protected public approach mentioned above; this worked with Linux/GCC, but failed with Windows and Visual Studio.
The reason was that changing protected to public also changed the mangled symbol name and thus gave me linker errors: the library provided a protected __declspec(dllexport) void Foo::bar() method, but with the #define in place, my test program expected a public __declspec(dllimport) void Foo::bar() method which gave me an unresolved symbol error.
For this reason, I switched to a friend based solution, doing the following in my class header:
// This goes in Foo.h
namespace unit_test { // Name this anything you like
struct FooTester; // Forward declaration for befriending
}
// Class to be tested
class Foo
{
...
private:
bool somePrivateMethod(int bar);
// Unit test access
friend struct ::unit_test::FooTester;
};
And in my actual test case, I did this:
#include <Foo.h>
#include <boost/test/unit_test.hpp>
namespace unit_test {
// Static wrappers for private/protected methods
struct FooTester
{
static bool somePrivateMethod(Foo& foo, int bar)
{
return foo.somePrivateMethod(bar);
}
};
}
BOOST_AUTO_TEST_SUITE(FooTest);
BOOST_AUTO_TEST_CASE(TestSomePrivateMethod)
{
// Just a silly example
Foo foo;
BOOST_CHECK_EQUAL(unit_test::FooTester::somePrivateMethod(foo, 42), true);
}
BOOST_AUTO_TEST_SUITE_END();
This works with Linux/GCC as well as Windows and Visual Studio.
A good approach to test the protected data in C++ is the assignment of a friend proxy class:
#define FRIEND_TEST(test_case_name, test_name)\
friend class test_case_name##_##test_name##_Test
class MyClass
{
private:
int MyMethod();
FRIEND_TEST(MyClassTest, MyMethod);
};
class MyClassTest : public testing::Test
{
public:
// ...
void Test1()
{
MyClass obj1;
ASSERT_TRUE(obj1.MyMethod() == 0);
}
void Test2()
{
ASSERT_TRUE(obj2.MyMethod() == 0);
}
MyClass obj2;
};
TEST_F(MyClassTest, PrivateTests)
{
Test1();
Test2();
}
See more Google Test (gtest).
Unit test VariableImpl such that if its behavior is ensured, so is Variable.
Testing internals isn't the worst thing in the world, but the goal is that they can be anything as long as the interfaces contracts are ensured. If that means creating a bunch of weird mock implementations to test Variable, then that is reasonable.
If that seems like a lot, consider that implementation inheritance doesn't create great separation of concerns. If it is hard to unit test, then that is a pretty obvious code smell for me.
While in my opinion the need of testing private members/methods of a class is a code smell, I think that is technically feasible in C++.
As an example, suppose you have a Dog class with private members/methods except for the public constructor:
#include <iostream>
#include <string>
using namespace std;
class Dog {
public:
Dog(string name) { this->name = name; };
private:
string name;
string bark() { return name + ": Woof!"; };
static string Species;
static int Legs() { return 4; };
};
string Dog::Species = "Canis familiaris";
Now for some reason you would like to test the private ones. You could use privablic to achieve that.
Include a header named privablic.h along with the desired implementation like that:
#include "privablic.h"
#include "dog.hpp"
then map some stubs according to types of any instance member
struct Dog_name { typedef string (Dog::*type); };
template class private_member<Dog_name, &Dog::name>;
...and instance method;
struct Dog_bark { typedef string (Dog::*type)(); };
template class private_method<Dog_bark, &Dog::bark>;
do the same with all static instance members
struct Dog_Species { typedef string *type; };
template class private_member<Dog_Species, &Dog::Species>;
...and static instance methods.
struct Dog_Legs { typedef int (*type)(); };
template class private_method<Dog_Legs, &Dog::Legs>;
Now you can test them all:
#include <assert.h>
int main()
{
string name = "Fido";
Dog fido = Dog(name);
string fido_name = fido.*member<Dog_name>::value;
assert (fido_name == name);
string fido_bark = (&fido->*func<Dog_bark>::ptr)();
string bark = "Fido: Woof!";
assert( fido_bark == bark);
string fido_species = *member<Dog_Species>::value;
string species = "Canis familiaris";
assert(fido_species == species);
int fido_legs = (*func<Dog_Legs>::ptr)();
int legs = 4;
assert(fido_legs == legs);
printf("all assertions passed\n");
};
Output:
$ ./main
all assertions passed
You can look at the sources of test_dog.cpp and dog.hpp.
DISCLAIMER: Thanks to insights of other clever people, I have assembled the aforementioned "library" able to access to private members and methods of a given C++ class without altering its definition or behaviour. In order to make it work it's (obviously) required to know and include the implementation of the class.
NOTE: I revised the content of this answer in order to follow directives suggested by reviewers.
I generally suggest testing the public interface of your classes, not the private/protected implementations. In this case, if it can't be observed from the outside world by a public method, then the unit test may not need to test it.
If the functionality requires a child class, either unit test the real derived class OR create your own test derived class that has an appropriate implementation.
Example from the Google testing framework:
// foo.h
#include "gtest/gtest_prod.h"
class Foo {
...
private:
FRIEND_TEST(FooTest, BarReturnsZeroOnNull);
int Bar(void* x);
};
// foo_test.cc
...
TEST(FooTest, BarReturnsZeroOnNull) {
Foo foo;
EXPECT_EQ(0, foo.Bar(NULL));
// Uses Foo's private member Bar().
}
The main idea is the use of the friend C++ keyword.
You can extend this example as follows:
// foo.h
#ifdef TEST_FOO
#include "gtest/gtest_prod.h"
#endif
class Foo {
...
private:
#ifdef TEST_FOO
FRIEND_TEST(FooTest, BarReturnsZeroOnNull);
#endif
int Bar(void* x);
};
You can define the TEST_FOO preprocessor symbol in two ways:
within the CMakeLists.txt file
option(TEST "Run test ?" ON)
if (TEST)
add_definitions(-DTEST_FOO)
endif()
as arguments to your compiler
g++ -D TEST $your_args