C unit testing framework?

Development archive
1

Hey,

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

2

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

3

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

4

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…

Thomas

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

5

Hi Thomas,

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

Cheers, Ludwig

6

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.

7

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

8

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