Gtest with large C and C ++ codebase

Question

I am into a project where we have a large codebase and currently it has no unit tests framework at all.The code we are working on would be finally run on a box which acts as a switch/router/firewall.

So I am working on a piece of code which needs to be unit-tested using Gtest. the problem I have with this is mocking the variables in order to test the function itself. For eg I have a function which uses like 4 pointers to different objects and uses couple of global variables .In order to test different paths in code I need to initialize almost the entire state machien/values of dependent variables. Adding to the complexity as it is true in a large codebase this function/method I have written uses a bunch of other routines/methods which needs to be tested as well. Each of those needs to be uni-tested as well with each of them having their own dependencies. I am not sure whether I am approching the problem right or is it the case that gtest may not be the right tool for testing such large code-base.

If anyone has experience with say testing say a call-stack say

function A {
    code 
    code
    function B
    code 
    code
    function C
    code
}

function B
{
    function D
    code
    function E
}

function C{
    code
    function F
    function G
    code
}

something like this.How do I test all these function A-F ?? What is a good strategy ??

Why is this tagged C++ when writing C code? BTW Global variables are a bad idea — Ed Heal, Sep 10 '14 at 19:06
The codebase has both C and C++.I know global variables is a bad idea.Thats how its been designed right now.Have to live with it :) — Satwik Krishna, Sep 10 '14 at 20:18
Testing large/complex code is NEVER easy. You need to write tests that work through your code, and often set up various objects. Where I work, the time to write tests is often 2-5x the time it takes to actually develop the real code. Only when the code to test is REALLY simple does that number go down towards 1.5 or 2x. Sometimes the test code can take 10+ times the original code-writing. — Mats Petersson, Sep 10 '14 at 20:20
Thanks Mats .Yeah I can imagine that.I was trying to document the dependencies I would need to track to test a single function/method and the mocking I need to do is a lot lot more.But have any of you written unit tests with gtest for such large/complex code ?? — Satwik Krishna, Sep 10 '14 at 20:24

score 2 · Answer 1 · answered Sep 11 '14 at 05:52

First thing is refactoring the code so that testable pieces are isolated. In particular, this means removing the access to globals. Example:

int global;
int function() {
    int r = foo();
    global += r / 2;
    bar(r);
    return 42;
}

Removing the global object means converting it to an input parameter:

int real_function(int* target) {
    assert(target);
    int r = foo();
    *target += r / 2;
    bar(r);
    return 42;
}

Then of course the remaining code will stop compiling, so you add a backward-compatibility cludge:

int global_bar;
// @deprecated, use real_function() directly
int function() {
    return real_function(&global_bar);
}

Using that, you step up the call chain, extracting the dependencies and hopefully one day removing the last call to the variant that requires the globals. In the meantime, you can write tests for the functions that don't depend on global stuff any longer. Note that for C++, you would use references instead of pointers and probably pass the required external objects to the class constructor. This is also called dependency injection, make sure to research that term for a thorough understanding.

Another way to test functions touching globals is to use the setup function of the test to reset the global to a known state. This still requires linking in the global though, which may prove difficult. And not using globals may make the codebase much better in the first place, so accepting that also sends the wrong message.

One thing to note is that additionally grouping related globals into structs will help you cut down on the number of parameters you need to pass to your functions. Without doing this you can easily end up with functions taking very large numbers of parameters. — Michael Anderson, Sep 11 '14 at 06:25
Another thing to watch out for in global ridden code is "hidden globals" in the form of function static variables, or thread local variables. — Michael Anderson, Sep 11 '14 at 06:28

score 0 · Answer 2 · answered Sep 11 '14 at 06:37

Ulrich Eckhardt essentially says, "You need to get rid of globals to make easily testable code". But you really should go further.

For any global function you want to test you should look at

The globals it accesses.
The parameters it uses.
the functions it calls.

Then consider:

Converting the functions it calls to calls to one or more interfaces, and pass those as parameters.
Converting the globals to parameters, or function calls on an interface.

If your function is a function on an object rather than a global function, you can consider additionally:

making the globals member variables, and passing them to the constructor
making the functions it calls virtual member functions

The final thing I'd consider for making a function testable, is whether it belongs in a class.

Once all these are addressed you can usually mock the required bits easily. If you're using gtest, you may be able to use gmock to make this easier. (I've used gmock with gtest before and its pretty painless.)

(And yes, I've taken this approach on large code-bases before... its usually pretty painful to start with, but once you get used to it and the code starts to get more testable - things will improve.)

Gtest with large C and C ++ codebase

2 Answers2