With our ExecutionPlatform, you can run unit tests directly on the target microcontroller (MCU). This is called on-target testing.

Executing unit tests on the MCU is similar to running firmware.
As a first step, the tests are compiled into a binary that can be executed on the MCU.

The ExecutionPlatform has built-in support for different unit testing frameworks. Examples for Unity & GoogleTests are available, other testing frameworks can be provided on request.

This article is based on the Unity framework but the same process applies to other frameworks as well.

Building the unit test

To get the first test running we need to create a source file that will act as a main file for attaching tests as described in the Unity documentation.

int run_tests() {
    return UNITY_END();

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

run_tests() function will be invoked by the ExecutionPlatform (see below) to run the tests.

Next we need to attach this file into the build system so that we can get a binary that can be loaded into the MCU and executed.
For that we need to add a CMakeLists.txt file that creates an executable and link it with the testing framework.
Depending on your tests you will need to add some include directories for header-files needed by your tests.

add_executable(unittests tests.cpp)
add_bin_from_elf(unittests unittests.bin)
target_link_libraries(unittests ep_app_unity)
# target_include_directories(unittests dir1 dir2)

After that make sure that the CMakeLists.txt you just created is included in your parent CMakeLists.txt file.

With all that done, reconfigure cmake so that your new executable is available as a build target. Now build your new executable with tests. When the build is successful, you will find a unittests.bin in the build dir.

Running tests

To run the tests we just built, we need to create a Robot Framework test file. This is needed to make the process of programming, running & evaluating results on the MCU simpler and easier to automate.

Use this template for running unit tests:

*** Settings ***
Library        ${ep_app_dir}/EP.py   ${ep_url}    ${ep_bsp_dir}/gpio.ep-config
Resource       ${ep_app_dir}/unity/unity.resource

*** Test Cases ***
Run reverse data tests
    DUT Flash Firmware    ${ep_binary_dir}/example/unittests.bin
    ${output} =    Run Unity Tests
    Log To Console    ${output}

In this file first we specify that we would like to use EP.py library. It is needed to communicate with ExecutionPlatform.
unity.resource contains helper keywords that simplify running tests.

In the *** Test Cases *** section, we define what should be run. In the most simple case you will only have one binary with tests cases that you would like to run. For this you only need one test case in the robot sequence. If your unit test suite grows it might exceed the available flash memory on the MCU. In this case it is necessary to split the test suites across multiple binaries. In this case you can add a robot test case tor each binary.

In the test case, we first need to load the firmware into the MCU.
To do this use the DUT Flash Firmware keyword with the binary as a parameter. Next we run the test suite on the chip with the Run Unity Tests helper keyword. Finally we print the output from the test framework to the console. The last step is optional but during development of tests it makes it easier to always see the test output.

Try it in your browser

In our Online Demo you can run unit test examples as well as other examples. Feel free to check it for yourself.