Why gcov and cmock can't be enabled together

[AhmedMagdy111]

I'm trying to generate coverage reports while using cmock and whenever i include "mock_*" and run gcov:all i get this warning ⚠️ WARNING: Found no coverage results for test_apis::apis.c and when i comment the #include "mock_apis.h" everything runs ok. After investigation i found that in case of including mock file that's the building objects
Compiling test_apis.c...
Compiling test_apis::mock_apis.c...
Compiling test_apis::test_apis_runner.c...
Compiling test_apis::unity.c...
Compiling test_apis::cmock.c...
and when i comment it the building objects are
Compiling test_apis.c...
Compiling apis.c with coverage...
Compiling test_apis::test_apis_runner.c...
Compiling test_apis::unity.c...
So I've tried to force it to compile the apis.c with coverage before compiling mocking but i couldn't.
Thanks for your help

[mvandervoord]

Hi. Do any of these #include statements include path information? For example #include "api/apis.h".

If so, it's very likely that your problem has nothing to do with mocks and everything to do with a parsing bug we found and have fixed in the 1.0.1 prereleases. Perhaps you can try the prerelease and see if it fixes your problem?

Otherwise, can you share the top of your test file so we can see the include section? I'd like to try to reproduce the problem.

[AhmedMagdy111]

I only include it as normal as i have used ceedling module:create as i remember
So in the test_apis.c file i include that
#include "Unity.h"
#include "apis.h"
#include "mock_apis.h"
So it works great with mocks and so on but it can't generate the coverage reports but when i tried to remove #include "mock_apis.h" it works perfectly and generate the coverage reports

[mvandervoord]

You need to include EITHER apis.h (which will tell Ceedling you want the real apis.c to be compiled and linked to the test) OR mock_apis.h (which will tell Ceedling you want the mocked version to be compiled and linked). When you include both, only the mock version is getting linked because it takes preference. In this case, you don't have any unit-under-test files being linked (meaning all your files being linked are the test framework, tests, and supporting mocks, etc... there is no "release" code being tested). Therefore no coverage is generated because there's nothing to calculate coverage on.

Make sense?

[AhmedMagdy111]

But if we added mock_apis.c path to the source path in the .yml it will generate the coverage reports of that mock file as it's compiled. So you tell me that we can not mix the normal api tests like TEST_ASSERT_EQUAL_INT(5,Add(2,3)) with the mock tests like Add_Expect_IgnoreAndReturn(5) in the testcases and apply coverage reports on ?

[mvandervoord]

Mocks and standard unit tests can both be used within the same test file, but you cannot mock the file that you are testing. Instead, the purpose of a mock is to mock the files that it interacts with.

Here's a silly contrived example. Let's say I have a file a.c:

#include "a.h"
#include "err.h"

int Add(int first, int second) 
{
    return first + second;
}

int SubtractPositiveOnly(int a, int b)
{
    if (a >= b)
        return a - b;
   
    write_error("whoops");
    return 0;
}

To test this file, I have something that looks like this:

#include "unity.h"
#include "a.h" // This makes a.c get compiled and linked.
#include "mock_err.h" // this makes a mock for err.h get generated, compiled, and linked.

void setUp() {}
void tearDown() {}

void test_Add_SHOULD_doBasicAddition(void)
{
    TEST_ASSERT_EQUAL_INT(5, Add(2,3) );
    // and probably more
}

void test_SubtractPositiveOnly_SHOULD_handlePositiveNumbers(void) 
{
    TEST_ASSERT_EQUAL_INT(1, SubtractPositiveOnly(3,2) );
    // and probably more
}

void test_SubtractPositiveOnly_SHOULD_handleErrorsForNegatives(void) 
{
    write_error_Expect("whoops");

    TEST_ASSERT_EQUAL_INT(0, SubtractPositiveOnly(2,3) );
}

As you can see, the above test focuses on testing module a.c. It uses a mix of standard unit tests and interaction tests with mocks. But it avoids using both the mock and real version of the same file. When it's time to test err.c, we'd link the REAL err.c and test it directly (possibly mocking things it calls, if needed).

[AhmedMagdy111]

That's great. I got you. That was very helpful. Thanks for your help.

[mvandervoord]

Of course. best of luck!