Unit test tasks: how to access static functions

flntobi wrote on Friday, July 15, 2016:


In order to program with the Test Driven Development (TDD) paradigm it is essential to unit test all modules. I use the simple unit test environment Unity. The idea of unit testing is to test all public functions. Static (i.e. private) functions are indirectly tested.
There are two problems with unit testing FreeRTOS code:

  1. Stubs (test environment) need to be created to mimic the FreeRTOS queue behaviour. I solved this by dividing the run function into two functions and calling them with the testinput for the queues:

static void run(void parameters)
encapsulated in extra function to allow unit testing */

  1. The problem with the FreeRTOS architecture is that the tasks are based on static functions (the run function). I solved this by using the preprocessor define “-Dstatic=”, which removes the keyword static from the code. This is not an elegant way because 1. the unittest is not run on the orignal code and 2. the static variables inside the functions become non static.
    Does anyone know a better solution to this problem?

Thanks in advance of any help

rtel wrote on Friday, July 15, 2016:

If you look at the bottom of tasks.c you will see the following code:

	#include "tasks_test_access_functions.h"

The header file is something you have to provide yourself, but allows
you to insert code into the source file that gives you access to all the
static functions and data the file contains. I don’t think there are
equivalents in the other source files (?) but you could use the same

richard_damon wrote on Friday, July 15, 2016:

FreeRTOS does NOT requrie tasks functions to be ‘static’, but can be global, letting you build a seperate test file that calls the task. You also can add a stub function that isn’t static that calls the task (and perhaps is only present when compiling for test).

My normal procedure is I do NOT make my task functions static, but also do not put an extern definition for them in a header file, so other files can’t accidently call it. This allows a test procedure to make the call as needed.