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 ??

Answer 1

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.

Answer 2

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.)