ZP 3 uses gtest for unit testing.

To run unit tests:

You can use the testing/test.bash script.

• To clean the unit testing build, use ./testing/test.bash clean

• To build the unit tests, use ./testing/test.bash build

• To run the built unit tests, use ./testing/test.bash run

• To only run a certain TestSuite of tests, use ./testing/test.bash run "<Suite regex>:*"

  • whatever you pass in as the second arg, will be used as the gtest filter. You can read about how to use it here: http://google.github.io/googletest/advanced.html#running-a-subset-of-the-tests

  • Please use quotation marks around the filter, as it can sometimes break on certain shells without quotation marks.

Alternatively, you can use docker to do all of this. Please refer to the How-To on using docker in zp3.

Working With Docker

To write unit tests:

unit tests are fairly straight forward, here are some things to remember:

• read this primer on gtest: http://google.github.io/googletest/primer.html

• make sure your tests are in <Manager>/tests

  • tests must be cpp files. Header files wont work and in my opinion do not meet the unit testing pattern/style.

  • Each unit test should be treated like it’s own main function (unless youre using test fixtures or other fancy gtest features).

• Any header you include must make no reference of STM32 specific things. The unit tests are built using gcc, which means the code must not be meant for ARM platform.

• By default, including a header from <Manager>/Inc will work, but if the functions in that header are implemented in a cpp file, it will need to be included in the CMakeLists.txt for testing. An example of that is here: https://github.com/UWARG/ZeroPilot-SW-3/blob/b34d1775bf22d4c90ea2e372442991cd34691a6b/testing/CMakeLists.txt#L39 where CRC32.cpp was added because the tests needed a function that was implemented there. If you have headers that are not in <Manager>/Inc, youll need to add them to CMakeLists, please let me know (SnackOverflowError#0543), I can fix the CmakeLists for you.

• Test naming: the test macro has 2 name fields. One for the group of tests (TestSuite) and one for the test itself. The TestSuite name should include whatever component is being tested (like TM for telemetry manager), so that the results can be understood, or so that its easier to only test a single component.

  • for example, when testing System manager, the name should be prefixed with SM, so that the user can choose to only run SM tests.