Writing unit-test and need to control the c++ linker - c++

Question

I am writing unit-tests for a C++ class that has dependencies on 3rd-party C and C++ libraries, as well as 1st-party C libraries. I am running into trouble, because I want the class under test to consume a mocked 3rd-party C library and the test runner to consume the REAL 3rd-party C library.
I am writing unit-tests, and the class under test has a dependency on libx.
I have created a libmockx which allows me to test parameters and inject return values.
The class under test, needs to link to libmockx so I can inspect and control it's behavior.
The unit test application, needs to link to libx in order to formulate/parse libx data types.
Which pattern or method is used to link the test runner to libx, the class under test to libmockx, then link the test-runner to the class under test? Many solutions discuss letting the linker do the "dirty work", but ld has 100s of parameters and I don't know how to make it work.
Currently, I have redefinition errors for all the mock implementations, and I need a way to work around it (whether that involves the linker or not).
EDIT BELOW: (in response to comments)
Imagine 7 files:
test.cpp - the test runner
object.cpp - the object under test
object.hpp - the object header
mock-parameters.h - provide mock parameter access to tests
mock-x.c - the mock implementation of x
x.c - the x implementation
x.h - the x header
Before I needed to instantiate and manipulate x objects, I was able to compile my test with a single call to g++:
g++ test.cpp object.cpp mock_x.c
I am trying to add a test to test.cpp, that will supply and test an x object result value. Now, I need to link test.cpp against x.c while still linking object.cpp against mock_x.c.
When I add x.c to the compilation list, I get the following (expected) error:
/usr/bin/ld: /tmp/ccDVQxtN.o: in function `set_foo(X*, int)':
mock-x.c:(.text+0x0): multiple definition of `set_foo(X*, int)'; /tmp/cc3t8CjP.o:x.c:(.text+0x14): first defined here
collect2: error: ld returned 1 exit status
x.h
#ifndef X_H
#define X_H
typedef struct X {
int foo;
char bar;
} X;
X * create_x (void);
int set_foo (X *, int);
char set_bar (X *, char);
void delete_x (X *);
#endif // X_H
x.c
#include "x.h"
#include "stdlib.h"
X * create_x (void) {
return (X *)malloc(sizeof(X));
}
int set_foo (X * x, int i) {
x->foo = i;
return i;
}
char set_bar (X * x, char c) {
x->bar = c;
return c;
}
void delete_x (X * x) {
free(x);
}
mock-x.c
#include "x.h"
#include "mock-parameters.h"
Set_foo_params set_foo_params;
int set_foo (X * x, int i) {
// Stash parameter(s)
set_foo_params.x = x;
set_foo_params.i = i;
return set_foo_params.result;
}
object.hpp
#ifndef OBJECT_HPP
#define OBJECT_HPP
#include "x.h"
class Object {
public:
void embed_x(X *);
int increment_foo(int);
private:
X * _x;
};
#endif // OBJECT_HPP
object.cpp
#include "object.hpp"
void Object::embed_x (X * x) {
_x = x;
}
int Object::increment_foo (int i) {
++i;
return set_foo(_x, i);
}
mock-parameters.h
#include "x.h"
typedef struct Set_foo_params {
X * x;
int i;
int result;
} Set_foo_params;
extern Set_foo_params set_foo_params;
test.cpp
#include "object.hpp"
#include "mock-parameters.h"
int test_object_update_foo_correctly_invokes_x_set_foo (void) {
int result;
Object object;
// Setup
X * x = create_x();
object.embed_x(x);
// Execute
object.increment_foo(7);
// Test
if (8 == set_foo_params.i) {
result = 0;
} else {
result = 1;
}
delete_x(x);
return result;
}
int test_object_update_foo_correctly_returns_x_set_foo_result (void) {
int result;
Object object;
// Setup
X * x = create_x();
object.embed_x(x);
set_foo_params.result = 5;
// Execute
int output = object.increment_foo(0);
// Test
if (5 == output) {
result = 0;
} else {
result = 2;
}
delete_x(x);
return result;
}
int main (void) {
int result;
result |= test_object_update_foo_correctly_invokes_x_set_foo();
result |= test_object_update_foo_correctly_returns_x_set_foo_result();
return result;
}

Answer 1

Since you clarified that your object.c and test.c use the same functions - but should use different implementations - the only way is to separate those functions in some way. According to ODR (One Definition Rule of C++ programming language) you cannot have two different implementations of the same function/object.
So the only way is to create two separate functions/objects (with a separate names). You can use different names or put the same names in different namespaces.
Example:
x.h:
#ifndef X_H
#define X_H
#ifdef X_DEBUG
#define X mock_x
#else
#define X x
#endif
namespace X {
int foo();
}
#endif // X_H
x.cpp:
namespace x {
int foo()
{
int res = -1;
// rightful implementation
return res;
}
}
mock-x.cpp:
namespace mock_x {
int foo()
{
int res = -1;
// mock implementation
return res;
}
}
object.cpp:
#define X_DEBUG
#include <x.h>
int obj_bar()
{
int res = X::foo(); // uses mock implementation
return res;
}
}
test.cpp:
#include <x.h>
int test_bar()
{
int res = X::foo(); // uses real implementation
return res;
}
}
Obviously this approach is scalable - you can put any number of classes/function/objects in this namespace X. Common functionality may be defined inline in the header <x.h> and separate functionality in corresponding modules x.c and mock-x.c.
In general:
I would definitely look in the direction of creating mock-x implementation as a distinct set of linker symbols. This is definitely much more controllable and flexible approach. You can even use original x API implementation from your mock-x functionality - e.g. as a fallback when appropriate.
EDIT:
For your specific newly added example code.
mock-x.c:
#include "x.h"
#include "mock-parameters.h"
Set_foo_params set_foo_params;
int mock_set_foo (X * x, int i) {
// Stash parameter(s)
set_foo_params.x = x;
set_foo_params.i = i;
return set_foo_params.result;
}
The rest of the files are unchanged.
GCC should compile object.cpp separately with command:
g++ -Dset_foo=mock_set_foo -c object.cpp -o object.o
g++ test.cpp object.o x.c mock_x.c
GCC option -Dset_foo=mock_set_foo works the same as
#define set_foo mock_set_foo
in the beginning of each source file in command line after this option.
This option is widely used for compile-time configuration purposes.