C unit testing framework?


Is there some recommendation in order to write unit tests that compare against expected values in RIOT?

I'm talking about some testing infrastructure like CUnit provides:

Example from [1]:

    int maxi(int i1, int i2)     {       return (i1 > i2) ? i1 : i2;     }

    void test_maxi(void)     {       CU_ASSERT(maxi(0,2) == 2);       CU_ASSERT(maxi(0,-2) == 0);       CU_ASSERT(maxi(2,2) == 2);     }

Is there something like that I can use within RIOT? Or do I have to implement my own test driver?

Disclaimer: I'm implementing CBOR-on-RIOT, and for the deserialization/serialization part it would help to have test infrastructure like that in order to compare against expected output.

[1] http://cunit.sourceforge.net/doc/writing_tests.html#tests

Hi Kevin,

for the RIOT core module we decided to use embUnit [1] and its implementation for core data structure is currently under review [2].

Cheers, Thomas

[1] http://embunit.sourceforge.net/embunit/index.html [2] https://github.com/RIOT-OS/RIOT/pull/961

Hi Kevin, hi Thomas not only core can be tested with it, but every module (though only tests for core are currently implemented). Feel free to add tests under tests/unittests.

Best, Martine

I’m pretty happy with the pytest framework [1], which has nice features such as test fixtures and JUnitXML output. To run unit tests on C code, I usually compile the code as a shared library and import it in Python (and pytest) using ctypes [2]. Since, in the OpenWSN project [3] we use Python and C a lot, this method allows us to keep the same test framework in both worlds, which is nice.

My 2 cents…


[1] http://pytest.org/ [2] https://docs.python.org/2/library/ctypes.html [3] http://www.openwsn.org/

Hi Thomas,

We need to be able to run the tests on microcontrollers, so Python is not an option.

Cheers, Ludwig

Interesting, I didn’t get that was one of your constraints. Running direct on the uC certainly allows other types of tests; I would, however call those functional tests rather than unit tests.

Well, we can’t assume tests have the same results on different architectures. Call it what you will, but it’s nice to be able to run the same tests on all platforms.

Cheers, Ludwig

Ludwig, I believe there is space for both types of testing: on-chip for hardware-dependent tests and off-chip for behavioral tests (e.g. "does my protocol implementation react as expected when receiving a malformed packet"). The latter is usually easier to automated when not tied to hardware (e.g. Travis). That's all I'm saying :slight_smile: Thomas