I want to create a unit test environment for our project. But I am lost about how to create mocks for members of the classes. I want to explain my question with an example.
In my older projects, we were using a mock selection mechanism which is very ugly in my opinion. Here is the elder method:
class member {
};
class member_mock_1 {
};
class member_mock_2 {
};
class parent {
#if defined UNIT_TEST_1
typedef member_t member_mock_1;
#elif defined UNIT_TEST_2
typedef member_t member_mock_2;
#else
typedef member_t member;
#endif
private:
member_t mem;
};
The first question is mocking the classes of the member object with typedefing in or out of the parent class is a proper way or not? What is the best practice? If I want to use a unit testing framework, like gtest, should I use this kind of way or is there another way to mocking members?
Note 1: If the virtual mechanism is activated, it is ok to create base classes to ease mocking, if a class is pod or something, I don't want to use this mechanism.
Note 2: I also find ugly passing the types of members as a template parameter, everything becomes template in the project. I don't want to do that. Here is an example:
template <typename M>
class parent {
private:
M mem;
};
#if defined UNIT_TEST_1
typedef parent_t parent<member_mock_1>;
#elif defined UNIT_TEST_2
typedef parent_t parent<member_mock_2>;
#else
typedef parent_t parent<member>;
#endif
Here is the method i am suggesting here:
member_mock_1.hpp
class member_mock_1 {
};
member_mock_2.hpp
class member_mock_2 {
};
mock.hpp
template <typename TYPE>
struct mock { using type = TYPE; };
#define ENABLE_MOCKING(NamE) \
using NamE ## _t = mock<NamE>::type
member_mock.hpp
#if define UNIT_TEST_1
template<>
struct mock<member> { using type = member_mock_1 };
#endif
#if define UNIT_TEST_2
template<>
struct mock<member> { using type = member_mock_2 };
#endif
member.hpp
class member {
};
ENABLE_MOCKING(member);
parent.hpp
class parent {
private:
member_t mem;
};
Method I have mentioned above works for normal classes. For template classes some extra works should be done, i think.
So as a conclusion, I am suggesting a structure for unit testing like above. May be it is unnecessary, there are some other mechanisms or ways to cover that requirement. Maybe I still reinventing the wheel :(
Please suggest a way you know for mocking members of a class.
Thanks.
Yes, You're reinventing the wheel the code looks really messy:
#if defined UNIT_TEST_1
typedef parent_t parent<member_mock_1>;
#elif defined UNIT_TEST_2
typedef parent_t parent<member_mock_2>;
#else
typedef parent_t parent<member>;
#endif
There are several tools available.
I use Typemock Isolator++ as you can mock pretty much everything without touching your production whatsoever.
One other thing, the behavior you set on a mock will be applied only in the scope of the test, so every test has an individual and independent setup.
You can access the member, even if it's private:
member* mock_member = FAKE<member>;
parent* my_parent = new parent();
ISOLATOR_SET_MEMBER(my_parent, mem, mock_member);
And easily get it:
member* get_member;
ISOLATOR_GET_MEMBER(my_parent, mem, get_member);
Also, it allows to fake abstract classes, global methods, pure virtual methods, private and protected methods, set up behaviors for it. Furthermore, access hidden data members and invoke them. Check this for more information.
I am in a similar situation to you - introducing unit tests to a legacy C++ project. To do so I have used a lot of preprocessor directives along with Google Test and Google Mock. Particularly, if I was facing to your example, I would do as follows:
#if defined UNIT_TEST
class imember
{
virtual void a_method() = 0;
};
#endif
class member
#if defined UNIT_TEST
: public imember
#endif
{
void a_method()
{
// do something
};
};
class parent {
public:
#if defined UNIT_TEST
parent(imember mem) : mem_(mem) {};
#endif
private:
#if defined UNIT_TEST
imember mem_;
#else
member mem_;
#endif
};
Now, use Google Mock to define a mock class:
class mockmember : public imember
{
public:
MOCK_METHOD0(a_method, void());
};
Mock class is now ready. Use Google Test to define your test scenarios:
class parenttest : public testing::Test
{
public:
parenttest() : member_(mockmember()), parent_(member_) {}
virtual void SetUp() {}
virtual void TearDown() {}
protected:
parent parent_;
mockmember member_;
};
TEST_F(parenttest, a_func)
{
EXPECT_CALL(member_, a_method());
int ret = parent_.a_func();
ASSERT_EQ(0, ret);
}
Disclaimer, i work in Typemock.
Sam is totally right.
Also, you don't need to create 3 different member_mock classes for every single unit-test.
You can simply set up the behavior, for example, for some private method in member:
member* mock_member = FAKE<member>;
PRIVATE_WHEN_CALLED(member, somePrivateMethod()).Return(0);
Next using PRIVATE_WHEN_CALLED(mock_member, somePrivateMethod()) will overload behavior for somePrivateMethod(), so, instead of creating huge amount of different mock-classes just change the behavior for you needs.
Hope it'll be useful for you!
Related
I want to test some code that is written to run on an embedded processor in a Visual Studio Native Unit Test project.
The TestMe class has several methods that are good candidates for testing, but the Foo and Bar classes directly access memory mapped registers that are only available on the embedded processor.
#pragma once
#include "Foo.h"
#include "Bar.h"
class TestMe
{
public:
TestMe(Foo& aFoo, Bar& aBar);
~TestMe();
float FooBar();
};
What is the best way to mock away these objects so that I can test the TestMe class?
Edit: For me the best way would be the one that interferes as little as possible with the software that is being tested.
"Best" is always subjective, but I like using templates for this kind of mocking:
template <typename TFoo, typename TBar>
class TestMeImpl
{
public:
TestMeImpl(TFoo& aFoo, TBar& aBar);
~TestMeImpl();
float FooBar();
};
using TestMe = TestMeImpl<Foo, Bar>;
You would write unit tests against TestMeImpl, but expose TestMe to your users.
Your Foo and Bar are passed to constructor by reference.
There are two approaches to this.
My personal favor is to use interface and leverage polymorphic objects.
So it looks like this:
class IFoo {
public:
virtual void someFunction() = 0;
};
class IBar {
public:
virtual void otherFunction() = 0;
};
class Foo : public IFoo {
....
void someFunction() {
}
};
class Bar : public IBar {
.....
void otherFunction() {
}
};
class TestMe {
public:
TestMe(IFoo& aFoo, IBar& aBar);
~TestMe();
float FooBar();
};
// test code (GMock example):
class MockFoo : public IFoo {
MOCK_METHOD(someFunction(), void());
};
class MockBar : public IBar {
MOCK_METHOD(otherFunction(), void());
};
TEST(TestMeTest, someTest)
{
MockBar bar;
MockFoo foo;
TestMe testMe(bar, foo);
EXPECT_CALL(bar, otherFunction());
EXPECT_EQ(0.2, testMe.FooBar());
}
This is basically same thing as use of templates. In this case dynamic polymorphism is used.
In case of template you got something similar so some people call it static polymorphism.
Both approaches have pros and cons and it is your decision which one is best in your case.
There is a solution to not introduce interfaces only for testing purposes (:
Link time substitution.
Rules:
Foo and Bar are in a static lib (there can be separate libs for Foo and Bar)
Don't link these libs to test exec.
Create a mock implementation that will be linked to test exec:
Hpp file:
#pragma once
#include <gmock/gmock.h>
class FooMock
{
FooMock();
~FooMock();
MOCK_METHOD0(foo, void());
};
Cpp file:
#include "Foo.hpp"
#include "FooMock.hpp"
namespace
{
FooMock* fooMock;
}
FooMock::FooMock()
{
assert(!fooMock);
fooMock = this;
}
FooMock::~FooMock()
{
fooMock = nullptr;
}
// Implement real Foo::foo
void Foo::foo()
{
// call FooMock::foo
fooMock->foo();
}
Disadvantage is that it won't work for multithread tests.
Hope it helps.
Depending on the size and performance constraints of the embedded platform introducing interfaces for the sole purpose of unit testing can be a bad idea. For small systems I favor the approach of type-aliasing classes which represent some kind of processor peripheral. I guess that's also what "Foo" and "Bar" in your example represent.
The right type alias for the current target can be chosen by using architecture predefines
struct Uart1 {};
struct Uart1Mock {};
#ifdef __x86_64__
using SensorUart = Uart1Mock;
#else
using SensorUart = Uart1;
#endif
The application code then simply uses SensorUart, no matter if the class depends on an actual serial port or simply uses standard io.
I'm writing for a project that uses makefile rules to switch between GPU and CPU implementations. I'd like to present an interface to user code that automatically switches between implementations without having to write #ifdef GPU_MODE all over the place.
My solution had been to use a templated interface class followed by alias templates (just typedefs, really, but I like the left-to-right style) like so:
namespace INTERFACE{
template <class VERSION>
class MyClass{
public:
MyClass():theClass(){};
//more methods...
private:
VERSION theClass;
};
}
using CpuMyClass = INTERFACE::MyClass<CpuMode>; //CpuMode defined elsewhere
#ifdef GPU_MODE
using MyClass = INTERFACE::MyClass<GpuMode>;
#else
using MyClass = INTERFACE::MyClass<CpuMode>;
#endif
Thus allowing outside code to use the symbol MyClass freely, trusting it to switch between modes automatically. Unfortunately using this is proving confusing. For example, I have a second class for which I'd like to write a ctor from MyClass:
#include "MyClass.hpp"
class OutsideClass{
public:
OutsideClass(const MyClass& A);
};
This ctor triggers an "identifier 'MyClass' is undefined" error. Does anyone know what's going on here?
Did you mean something like:
struct GpuMode { };
struct CpuMode { };
namespace INTERFACE {
// ~~~~~~~~^^^^^^
template <class VERSION>
class MyClass{
public:
MyClass() : theClass(){};
//more methods..
private:
VERSION theClass;
};
}
using CpuMyClass = INTERFACE::MyClass<CpuMode>; //CpuMode defined elsewhere
#ifdef GPU_MODE
using MyClass = INTERFACE::MyClass<GpuMode>;
#else
using MyClass = INTERFACE::MyClass<CpuMode>;
#endif
class OutsideClass{
public:
OutsideClass(const MyClass& A);
};
Demo
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.
My class uses the PImpl idiom and looks something like this:
// In LongDescriptiveClassName.hpp
class LongDescriptiveClassName
{
public:
// Stuff...
private:
struct LongDescriptiveClassNameData;
LongDescriptiveClassNameData &Data;
};
In the .cpp file, I declare/define the private struct:
// In LongDescriptiveClassName.cpp
struct LongDescriptiveClassName::LongDescriptiveClassNameData
{
void PrivateMethod1();
void PrivateMethod2();
// and so on...
};
void LongDescriptiveClassName::LongDescriptiveClassNameData::PrivateMethod1()
{
// Stuff...
}
void LongDescriptiveClassName::LongDescriptiveClassNameData::PrivateMethod2()
{
// Stuff...
}
This is painful for me to read. Is there a way that I can abbreviate the names leading up to the private methods?
My understanding is that I can't typedef it in the .cpp file because the PImpl struct is private. Would it be an evil to use #define?
#define ShortName LongDescriptiveClassName::LongDescriptiveClassNameData
struct ShortName
{
// ...
};
void ShortName::PrivateMethod1()
// ...
This .cpp file is the only source file that would need to abbreviate it, and then only for method definitions. What do you recommend?
The class name is already a namespace, so there's no reason to give the impl such a long name:
class LongDescriptiveClassName
{
public:
// Stuff...
private:
struct Impl;
// shared_ptr is also an option if that's
// the semantics you want.
std::unique_ptr<Impl> Data;
};
// and off in the implementation, we have...
struct LongDescriptiveClassName::Impl
{
void PrivateMethod1();
void PrivateMethod2();
// and so on...
};
void LongDescriptiveClassName::Impl::PrivateMethod1()
{
// Stuff...
}
It works just fine.
Incidentally, your code is not an example of the pimpl idiom. The "p" in "pimpl" means "pointer", and this is important. A reference means that the object does not own its implementation.
It's not necessarily wrong; there are sometimes good reasons to wrap a reference in a class, but it's not the pimpl idiom.
I'm not completely sure to understand your problem but it seems that a proper use of the using keyword should help a lot. Isn't
using ShortName = LongDescriptiveClassName::LongDescriptiveClassNameData
what you are looking for ?
Note this only work is LongDescriptiveClassNameData is a type not a data.
While #Pseudonym's solution is absolutely fine, I prefer to use names with initial upper case only for types, so I think I'd just do:
class LongDescriptiveClassName {
private:
struct Data;
Data &data;
};
I like to call it Impl, or Detail (though the latter is common as a namespace detail, also).
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