I am using ceedling to unit test a C application and trying to achieve high coverage ~100%.
I have a static callback function in one of my application module, which is registered to SDK function with function pointer and is called at certain event from the SDK.
In appModule.c,
typedef void( *type_appCallback ) ( void );
static void appCallback( void );
I want to unit test this function and since this functions is static will not be seen in the ceedling test_appModule.c.
I have a work around to this define TEST_STATIC instead of static,
#ifdef TEST
TEST_STATIC
#else
TEST_STATIC static
#endif
But I am not big fan of this work around, any suggestions to above problem?
As a workaround you could use a wrapper module that includes the C file.
wrap_app_Module.c
/* include code of static function (.c is intentional, not .h) */
#include "appModule.c"
void wrap_appCallback(void)
{
appCallback();
}
Instead of the static function you can call the wrapper function in your tests.
I did something similar to what #Bodo suggested above using the CMock callback plugin. Note the cmockNumCalls is a mandatory parameter for the stub function
Production code -> setCallback( funcAddress );
Unit Test code -> setCallback_Stub( storeFuncAddress );
Where storeFuncAddress looks like
void storeFuncAddress(
type_appCallback appCallbackFn,
int cmockNumCalls)
{
l_storedCallbackFn = appCallbackFn;
}
When the _Stub version gets called it passes the same parameters to the registered callback function so storeFuncAddress receives the same function address (which is a pointer to a static) and stores it in a variable of type type_appCallback which I'm calling l_storedCallbackFn.
The second part is where the event gets triggered.
Production code -> triggerCallback();
Unit Test code -> triggerCallback_Stub( runStoredCallbackFunction );
Where my runStoredCallbackFunction function looks like
void runStoredCallbackFunction(
int cmockNumCalls)
{
(*l_storedCallbackFn)(NULL);
}
Hopefully this helps you or the next person who runs across this same question.
I have a C project with 2 modules - A and B.
B has a function that calls a function from A.
int B_func() {
if (1 == A_func()) {return 1;}
return 2;
}
I use unity to test these modules.
TEST(B, test_b) {
TEST_ASSERT_EQUAL(1, B_func())
}
When I test module B, I want to mock A_func so it will use my implementation and change the return value. Is there a way to do this without changing the source code of module B?
I ended up using Mimick.
https://github.com/diacritic/Mimick
It's a bit cumbersome. I needed to compile my project as a shared object and link it to my tests so my functions will be in the GOT, so it is not ideal, but successfully solves my problem.
I am new to gmock, so I want to know how can I stub simple C function called in a function under test for Unit Testing.
Example:
int func(int a)
{
boolean find;
// Some code
find = func_1();
return find;
}
I have searched about gmock and in my understanding gmock does not provide functionality to stub simple C functions, therefore I want to ask does gmock provides functionality to mock or stub func_1?
If not how can I stub func_1 manually in my test code without changing source code? I am using google test framework for unit testing.
Thanks.
This is another answer of mine to this question. In the two years that passed since the first answer, I came to understand that GMock is simply the wrong framework for mocking C functions. In situations where you have a lot of functions to mock, my previously posted answer is simply too cumbersome. The reason is that GMock uses Object Seams to replace production code with mock code. This relies on polymorphic classes, which don't exist in C.
Instead, to mock C functions, you should use Link Seams, which replace the production code with the mock code at link time. Several frameworks exist for this purpose, but my favorite one is the Fake Function Framework (FFF). Check it out, it's a lot simpler than GMock. It also works perfectly well in C++ applications.
For the interested, here is a good article by Michael Feathers about the different seam types.
I found myself in the same situation lately. I had to write unit tests for
libraries written in C, which in turn had dependencies to other libraries also written in C. So I wanted to mock all function calls of dependencies
using gmock. Let me explain my approach by an example.
Assume the code to be tested (library A) calls a function from another library, lib_x_function():
lib_a_function()
{
...
retval = lib_x_function();
...
}
So, I want to mock the library X. Therefore I write an interface class and a
mock class in a file lib_x_mock.h:
class LibXInterface {
public:
virtual ~LibXInterface() {}
virtual int lib_x_function() = 0;
}
class LibXMock : public LibXInterface {
public:
virtual ~LibXMock() {}
MOCK_METHOD0(lib_x_function, int());
}
Additionally I create a source file (say, lib_x_mock.cc), that defines a stub
for the actual C function. This shall call the mock method. Note the extern
reference to the mock object.
#include lib_x.h
#include lib_x_mock.h
extern LibXMock LibXMockObj; /* This is just a declaration! The actual
mock obj must be defined globally in your
test file. */
int lib_x_function()
{
return LibXMockObj.lib_x_function();
}
Now, in the test file, which tests the library A, I must define the mock object
globally, so that it is both reachable within your tests and from
lib_x_mock.cc. This is lib_a_tests.cc:
#include lib_x_mock.h
LibXMock LibXMockObj; /* This is now the actual definition of the mock obj */
...
TEST_F(foo, bar)
{
EXPECT_CALL(LibXMockObj, lib_x_function());
...
}
This approach works perfectly for me, and I have dozens of tests and several
mocked libraries. However, I have a few doubts if it is ok to create a
global mock object - I asked this in a separate question and still wait for answers. Besides this I'm happy with the solution.
UPDATE: The problem about the global object can be easily remedied by creating the object e.g. in the constructor of the test fixture, and just storing a pointer to that object in a global variable.
However, also note my alternative answer to this question, that I just posted.
I was looking already a long time for a solution to mock legacy c-functions with googleMock without changing existing code and last days I found the following really great article: https://www.codeproject.com/articles/1040972/using-googletest-and-googlemock-frameworks-for-emb
Today I wrote my first unit test for c-functions using gmock and took as example two functions from the bcm2835.c library (http://www.airspayce.com/mikem/bcm2835/) for raspberry Pi programming:
Here is my solution: I'm using the gcc 4.8.3. under Eclipse and Windows. Be Aware to set the Compiler option -std=gnu++11.
Here are my functions to be tested
int inits(void);
void pinMode(uint8_t pin, uint8_t mode);
int inits(){
return bcm2835_init();
}
void pinMode(uint8_t pin, uint8_t mode){
bcm2835_gpio_fsel(pin, mode);
}
Includes and defines for unit testing with googleTest / googleMock
// MOCKING C-Functions with GMOCK :)
#include <memory>
#include "gtest/gtest.h"
#include "gmock/gmock.h"
using namespace ::testing;
using ::testing::Return;
Mock BCM2835Lib functions
class BCM2835Lib_MOCK{
public:
virtual ~BCM2835Lib_MOCK(){}
// mock methods
MOCK_METHOD0(bcm2835_init,int());
MOCK_METHOD2(bcm2835_gpio_fsel,void(uint8_t,uint8_t));
};
Create a TestFixture
class TestFixture: public ::testing::Test{
public:
TestFixture(){
_bcm2835libMock.reset(new ::testing::NiceMock<BCM2835Lib_MOCK>());
}
~TestFixture(){
_bcm2835libMock.reset();
}
virtual void SetUp(){}
virtual void TearDown(){}
// pointer for accessing mocked library
static std::unique_ptr<BCM2835Lib_MOCK> _bcm2835libMock;
};
Instantiate mocked lib functions
// instantiate mocked lib
std::unique_ptr<BCM2835Lib_MOCK> TestFixture::_bcm2835libMock;
Fake lib functions to connect Mocks with the c-functions
// fake lib functions
int bcm2835_init(){return TestFixture::_bcm2835libMock->bcm2835_init();}
void bcm2835_gpio_fsel(uint8_t pin, uint8_t mode){TestFixture::_bcm2835libMock->bcm2835_gpio_fsel(pin,mode);}
Create unit testing class for BCM2835 from TestFixture
// create unit testing class for BCM2835 from TestFixture
class BCM2835LibUnitTest : public TestFixture{
public:
BCM2835LibUnitTest(){
// here you can put some initializations
}
};
Write the Tests using googleTest and googleMock
TEST_F(BCM2835LibUnitTest,inits){
EXPECT_CALL(*_bcm2835libMock,bcm2835_init()).Times(1).WillOnce(Return(1));
EXPECT_EQ(1,inits()) << "init must return 1";
}
TEST_F(BCM2835LibUnitTest,pinModeTest){
EXPECT_CALL(*_bcm2835libMock,bcm2835_gpio_fsel( (uint8_t)RPI_V2_GPIO_P1_18
,(uint8_t)BCM2835_GPIO_FSEL_OUTP
)
)
.Times(1)
;
pinMode((uint8_t)RPI_V2_GPIO_P1_18,(uint8_t)BCM2835_GPIO_FSEL_OUTP);
}
Results :)
[----------] 2 tests from BCM2835LibUnitTest
[ RUN ] BCM2835LibUnitTest.inits
[ OK ] BCM2835LibUnitTest.inits (0 ms)
[ RUN ] BCM2835LibUnitTest.pinModeTest
[ OK ] BCM2835LibUnitTest.pinModeTest (0 ms)
[----------] 2 tests from BCM2835LibUnitTest (0 ms total)
Hope it will help :) - for me this is a really working solution.
You can use the Cutie library to mock C function GoogleMock style.
There's a full sample in the repo, but just a taste:
INSTALL_MOCK(close);
CUTIE_EXPECT_CALL(fclose, _).WillOnce(Return(i));
I had a similar case in a project I was unit-testing. My solution was to create two make files, one for production and one for testing.
If the function func_1() is definded in the header a.h, and implemented in a.cpp, then for testing you can add a new source file a_testing.cpp, that will implement all the functions in a.h as a stub.
For unittesting, just compile and link with a_testing.cpp instead of a.cpp and the tested code will call your stub.
In a_testing.cpp you can then forward the call to a gmock object that will set expectations and actions as usual based on the state and paramteres.
I know it's not perfect, but it works ans solve the problem without changing production code or interfaces at all.
In each UT we are trying to verify a specific behavior.
You should fake something when it's very hard/impossible(we need to isolate our unit)/spend a lot of time(running time..) to simulate a specific behavior.
Using a 'C' function in the explicit way means that the function is apart of your unit(therefore you shouldn't mock it..). In this answer I explain the initiative to test the method as is(in the edit..). In my opinion you should call func with the parameters which cause func_1 to simulate the behavior you want to verify.
GMock is based on compilation fake(macros), therefore you cannot do such a thing. To fake 'C' methods you have to use a different tools such as Typemock Isolator++.
If you don't want to use Isolator++, then you should refactor your method; Change func to func(int a, <your pointer the function>) and then use the pointer instead of func_1.
My chart in this answer might help to decide the way to handle your case.
This might not totally fit your case, but if you find yourself writing C code that needs to be stubbed (e.g. you want to stub some I/O connection), you could use function pointers.
So let's say you have a header and source file with the following function declaration and definition:
some_file.h
// BEGIN SOME_FILE_H
#ifndef SOME_FILE_H
#define SOME_FILE_H
#include <stdbool.h>
bool func_1(void);
#endif // SOME_FILE_H
// END SOME_FILE_H
some_file.c
// BEGIN SOME_FILE_C
#include "some_file.h"
bool func_1(void) {
return true;
}
// END SOME_FILE_C
Now, if you would like to stub this method, all you have to do is convert this method into a function pointer.
You will also have to adjust the .c file, since we changed the function and made it a function pointer.
some_file.h
// BEGIN SOME_FILE_H
#ifndef SOME_FILE_H
#define SOME_FILE_H
#ifdef __cplusplus
extern "C" {
#endif
#include <stdbool.h>
extern bool (*func_1)(void);
#ifdef __cplusplus
}
#endif
#endif // SOME_FILE_H
// END SOME_FILE_H
some_file.c
// BEGIN SOME_FILE_C
#include "some_file.h"
// Make the method static, so that it cannot be accessed anywhere else except in this file
static bool func_1_Impl(void) {
return true;
}
bool (*func_1)(void) = func_1_Impl;
// END SOME_FILE_C
You don't have to adjust the function calls anywhere else, since func_1 will simply be redirected to func_1_Impl.
Now for stubbing this method:
In your *_test.cc file (or whatever you call your test file), you can create a mock class with the same interface as some_file.h.
You can then overwrite the function pointer with the defined mock function.
some_file_test.cc
#include <gtest/gtest.h>
#include <gmock/gmock.h>
#include "some_file.h"
#include "header_where_func_is_declared.h"
using ::testing::AtLeast;
class SomeFile {
public:
virtual bool func1() = 0;
};
class MockSomeFile : SomeFile {
public:
MOCK_METHOD(bool, func1, (), (override));
};
TEST(Func1Test, ShouldMockStuff) {
// Arrange
auto expected = 0; // or whatever the expected result is
// Define the mock object to be used
static MockSomeFile mock;
// The important part: Overwrite the function pointer (with a lambda function)
func_1 = []() { return mock.func1(); };
// Define the call expectations
EXPECT_CALL(mock, func1)
.Times(AtLeast(1));
// Act
auto actual = func();
// Assert
EXPECT_EQ(expected, actual);
}
This test should pass, showing that the mocking worked.
You can also check, whether the test will fail, if you change the EXPECT_CALL call, e.g. set .Times(AtLeast(2)).
Note: You might see that the adjusted test passed with AtLeast(2), although this is wrong. You should still see the correct error message in the console.
I hope this helps you and everyone else who has a similar problem!
I have a DLL which contains many large (1000+ line) functions. This code has lots of complex logic which I want to ensure doesn't get broken when its maintained so I created a test harness which dynamically loads this DLL and calls its API.
I would like to know a nice way of being able to test which branches of the code where hit within this API from my test harness. The only way I can think of doing this is as follows:
// Pseudo test code
void doTest()
{
loadDllToBeTested();
dll_api_function_1();
assert( dll_api_function_1_branches.branch1Hit == true );
unloadDllToBeTested();
}
// Real api in the C dll
struct dll_api_function_1_branches
{
bool branch1Hit;
}
dll_api_function_1_branches g_dll_api_function_1_branches;
int private_func1()
{
printf("Doing my private stuff\n");
return 1;
}
void dll_api_function_1(void)
{
if ( private_func1() )
{
printf("doing some stuff\n");
dll_api_function_1_branches.branch1Hit = true; // so the test code can check if we got here :(
}
else
{
printf("doing some other stuff\n");
}
// tons of other logic and branching...
}
Which is basically have a struct per function which has values set when certain branches are reached within the function. There would be a global exported instance of this struct which the test code would have to init to zero and then check after calling the API.
Also note that I'm using Visual Studio so tools like gcov can't be used here.
The LLVM project mentions the KLEE tool, which helps creating test cases to exercise all paths (and find bugs in the process). Some of it is strongly Unix-oriented, and it is a current research project (rough edges, some assembly required, and the other disclaimers).
I have a few static util methods in my project, some of them just pass or throw an exception. There are a lot of examples out there on how to mock a static method that has a return type other than void. But how can I mock a static method that returns void to just "doNothing()"?
The non-void version uses these lines of code:
#PrepareForTest(StaticResource.class)
...
PowerMockito.mockStatic(StaticResource.class);
...
Mockito.when(StaticResource.getResource("string")).thenReturn("string");
However if applied to a StaticResources that returns void, the compile will complain that when(T) is not applicable for void...
Any ideas?
A workaround would probably be to just have all static methods return some Boolean for success but I dislike workarounds.
You can stub a static void method like this:
PowerMockito.doNothing().when(StaticResource.class, "getResource", anyString());
Although I'm not sure why you would bother, because when you call mockStatic(StaticResource.class) all static methods in StaticResource are by default stubbed
More useful, you can capture the value passed to StaticResource.getResource() like this:
ArgumentCaptor<String> captor = ArgumentCaptor.forClass(String.class);
PowerMockito.doNothing().when(
StaticResource.class, "getResource", captor.capture());
Then you can evaluate the String that was passed to StaticResource.getResource like this:
String resourceName = captor.getValue();
Since Mockito 3.4.0, an experimental API was introduced to mock static methods.
The following example code has been tested with Mockito 4.3.1 (testImplementation("org.mockito:mockito-inline:4.3.1), and JUnit Jupiter 5.8.2, OpenJDK 11.
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
import org.mockito.MockedStatic;
import org.mockito.Mockito;
import java.util.UUID;
public class StaticMockTest {
#Test
void showCaseStaticMock() {
try (MockedStatic<StaticMockTest> staticMock = Mockito.mockStatic(StaticMockTest.class)) {
staticMock.when(StaticMockTest::getUUIDValue).thenReturn("Mockito");
Assertions.assertEquals("Mockito", StaticMockTest.getUUIDValue());
}
// Regular UUID
UUID.fromString(StaticMockTest.getUUIDValue());
}
public static String getUUIDValue() {
return UUID.randomUUID().toString();
}
}
Previous Answer, probably Mockito 1.x/2.x with Powermock 1.x/2.x
You can do it the same way you do it with Mockito on real instances. For example you can chain stubs, the following line will make the first call do nothing, then second and future call to getResources will throw the exception :
// the stub of the static method
doNothing().doThrow(Exception.class).when(StaticResource.class);
StaticResource.getResource("string");
// the use of the mocked static code
StaticResource.getResource("string"); // do nothing
StaticResource.getResource("string"); // throw Exception
Thanks to a remark of Matt Lachman, note that if the default answer is not changed at mock creation time, the mock will do nothing by default. Hence writing the following code is equivalent to not writing it.
doNothing().doThrow(Exception.class).when(StaticResource.class);
StaticResource.getResource("string");
Though that being said, it can be interesting for colleagues that will read the test that you expect nothing for this particular code. Of course this can be adapted depending on how is perceived understandability of the test.
By the way, in my humble opinion you should avoid mocking static code if your crafting new code. At Mockito we think it's usually a hint to bad design, it might lead to poorly maintainable code. Though existing legacy code is yet another story.
Generally speaking if you need to mock private or static method, then this method does too much and should be externalized in an object that will be injected in the tested object.
Hope that helps.
Regards
In simpler terms,
Imagine if you want mock below line:
StaticClass.method();
then you write below lines of code to mock:
PowerMockito.mockStatic(StaticClass.class);
PowerMockito.doNothing().when(StaticClass.class);
StaticClass.method();
To mock a static method that return void for e.g. Fileutils.forceMKdir(File file),
Sample code:
File file =PowerMockito.mock(File.class);
PowerMockito.doNothing().when(FileUtils.class,"forceMkdir",file);