Function mocking (for testing) in C?

Question

I would like to write tests for a C library, in C. I'd like to mock out some functions for the test.

Suppose my library is compiled from the following source:

/* foo.h */
int myfunction(int x, int y);

/* foo.c */
#include "foo.h"

static int square(int x) { return x * x; }

int myfunction(int x, int y) {
    return square(x) + square(y);
}

I want to write a test like this:

/* foo_test.c */
#include "foo.h"

static int square(int x) { return x + 1; }

int main(void) {
    assert(myfunction(0, 0) == 2);
    return 0;
}

Is there any way I can compile so that myfunction will use the definition of square in foo_test.c, instead of the one in foo.c, only when linking the executable foo_test? That is, I want to compile foo.c into a library (let's call it libfoo.so), and then compile foo_test.c with libfoo.so and some magic so that I'll get an executable foo_test which uses the different implementation of square.

It would be helpful to hear solutions for when square is not declared static, but solving the above case would be even better.

EDIT: It seems hopeless, but here's an idea: Suppose I compile with -O0 -g so it's unlikely that square will get inlined and I should have symbols showing where the call was resolved. Is there a way to sneak into the object file and swap out the resolved reference?

Icelandic

LD_PRELOAD can give this to you, but I'm hoping someone else has a better answer. – Jointly

Not for static functions – Uniliteral

I don't think LD_PRELOAD is going to do it. I want to be able to change a function (that might be static) inside a library that's already compiled. As I understand (and maybe this is false), the symbol square inside myfunction will already be resolved before I try to link foo_test. – Icelandic

When your function is static, then the answer is no, you absolutely cannot do that. Static functions may be inlined and optimized out of existence altogether. – Teens

@n.m.: Non-static functions may also be inlined and optimized out of existence as well. Modern compilers with link-time optimization will do that, both GCC and Clang/LLVM are examples. – Nette

@DietrichEpp: In ELF systems, they shouldn't, since they should be able to be interposed by LD_PRELOAD. – Chela

@ninjalj: That only applies to symbols exported dynamically, which is why it never applies to static symbols and only sometimes applies to extern symbols. – Nette

What you are looking for is described in this article: Unit testing with mock objects in C – Steffie

Answer 1

It looks like you are using GCC, so you can use the weak attribute:

The weak attribute causes the declaration to be emitted as a weak symbol rather than a global. This is primarily useful in defining library functions which can be overridden in user code, though it can also be used with non-function declarations. Weak symbols are supported for ELF targets, and also for a.out targets when using the GNU assembler and linker.

http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

Legislate

Thanks. I can probably take it from here, but can you give me any tips on modifying a weak reference? – Icelandic

Just define a function with the same name that is NOT weak, then it should override the weak function in the library. – Legislate

When you have a single unit test target that in one file would use a real implementation of some function and then a mocked one in a different one, this doesn't really help at all - you'd get a mocked implementation in both of these. – Olivas

Answer 2

I wrote Mimick, a mocking/stubbing library for C functions that address this.

Assuming that square isn't static nor inline (because otherwise it becomes bound to the compilation unit and the functions that uses it) and that your functions are compiled inside a shared library named "libfoo.so" (or whatever your platform's naming convention is), this is what you would do:

#include <stdlib.h>
#include <assert.h>
#include <mimick.h>

/* Define the blueprint of a mock identified by `square_mock`
   that returns an `int` and takes a `int` parameter. */
mmk_mock_define (square_mock, int, int);

static int add_one(int x) { return x + 1; }

int main(void) {
    /* Mock the square function in the foo library using 
       the `square_mock` blueprint. */
    mmk_mock("square@lib:foo", square_mock);

    /* Tell the mock to return x + 1 whatever the given parameter is. */
    mmk_when(square(mmk_any(int)), .then_call = (mmk_fn) add_one);

    /* Alternatively, tell the mock to return 1 if called with 0. */
    mmk_when(square(0), .then_return = &(int) { 1 });

    assert(myfunction(0, 0) == 2);

    mmk_reset(square);
}

This is a full blown mocking solution though, and if you only want to stub square (and don't care about testing interactions), you could do something similar:

#include <stdlib.h>
#include <assert.h>
#include <mimick.h>

static int my_square(int x) { return x + 1; }

int main(void) {
    mmk_stub("square@lib:foo", my_square);

    assert(myfunction(0, 0) == 2);

    mmk_reset(square);
}

Mimick works by using some introspection on the running executable and poisoning at runtime the global offset table to redirect functions to the stub of our choice.

Binni

Answer 3

No, there's no solution for this. If there's a function in scope with a name matching a function call within a source file, that function will be used. No declaration trickery is going to talk the compiler out of it. By the time the linker is active, the name reference will have already been resolved.

Yongyoni

Check my answer below, suggesting a solution. would love to hear feedback about structuring the code this way. – Insider

Answer 4

Given that square() can be declared globally, you can use the Nala test framework to replace the implementation of square().

All source code, including a makefile, is available here.

The header file foo.h.

int square(int x);
int myfunction(int x, int y);

The source file foo.c.

#include "foo.h"

int square(int x) { return x * x; }

int myfunction(int x, int y) {
    return square(x) + square(y);
}

The test file test_foo.c, implementing the test in two alternative ways; replace implementation (as asked for) and expect-return.

#include "foo.h"
#include "nala.h"
#include "nala_mocks.h"

static int my_square(int x) { return x + 1; }

/* Replace the implemenation of square(). */
TEST(implementation)
{
    square_mock_implementation(my_square);

    ASSERT_EQ(myfunction(0, 0), 2);
}

/* Expect square(x=0) and return 1. */
TEST(mock)
{
    square_mock(0, 1);

    ASSERT_EQ(myfunction(0, 0), 2);
}

Vernacularize

Answer 5

Am I guessing correctly that:

a) you want your test to use a fake implementation of the int square(int x) function

b) int my_function(int x, int y) and int square(int x) are just toy examples, the real int square(int x) function in question is much more complicated, and that's why you want a lightweight int square(int x) implementation for tests.

?

If yes, you can achieve (a) and (b) by structuring the files differently:

1. Declare an "interface" for the int square(int x) function in a separate square.h file:

// square.h
int square(int x);

2. Define a real implementation of the int square(int x) function in a square.c file

// square.c
#include "square.h"

int square(int x) {
   return x * x;
}

3. Declare and implement int my_function(int x, int y) as usual:

// foo.h
int my_function(int x, int y);

// foo.c
#include "square.h" // Include only the interface for square(x), not implementation
int my_function(int x, int y) {
    return square(x) + square(y);
}

4. In tests, provide a fake implementation for the function int square(int x):

// foo_test.c
#include "my_function.h"
#include "square.h" // Include only the interface for square(x), not implementation
    
// Provide a fake implementation in the test file
int square(int x) {
   return x + 1;
}
    
// Run the actual test
void main() {
 assert(my_function(0, 0) == 2);
 return 0;
}

Insider

Answer 6

In cases like yours I use Typemock Isolator++ API.

It allows you to replace method's original behavior by your own implementation. But, due language specifics, you should avoid same names for functions under and for tests.

#include "foo.h"

static int square_test(int x) { return x + 1; }

TEST_CLASS(ArgumentTests)
{
public:
    TEST_METHOD_CLEANUP(TearDown)
    {
        ISOLATOR_CLEANUP();
    }

    TEST_METHOD(TestStaticReplacedStatic)
    {
        PRIVATE_WHEN_CALLED(NULL, square).DoStaticOrGlobalInstead(square_test, NULL);
        Assert::IsTrue(myfunction(0, 0) == 2);
    }
};

Hope it'll be useful for you, good luck!

Weig

The question is about C, but your answer is about C++. – Garman

@SimonKissane Actually, the answer is about C, but the framework is in C++ so you are partly correct. I should've mentioned that. – Weig