Unit Tests
Last updated
Last updated
Developers are encouraged to write unit tests during all parts of development, including adding new features, fixing bugs, and refactoring.
PX4 provides several methods for writing unit tests:
Unit tests with ("GTest") - tests that have minimal, internal-only dependencies
Functional tests with GTest - tests that depend on parameters and uORB messages
SITL unit tests. This is for tests that need to run in full SITL. These tests are much slower to run and harder to debug, so it is recommended to use GTest instead when possible.
Tip: In general, if you need access to advanced GTest utilities, data structures from the STL or need to link to parameters
or uorb
libraries you should use the functional tests instead.
The steps to create new unit tests are as follows:
Unit tests should be arranged in three sections: setup, run, check results. Each test should test one very specific behavior or setup case, so if a test fails it is obvious what is wrong. Please try to follow these standards when possible.
Copy and rename the example unit test to the directory the code to be tested is in.
Add the new file to the directory's CMakeLists.txt
. It should look something like px4_add_unit_gtest(SRC MyNewUnitTest.cpp LINKLIBS <library_to_be_tested>)
Add the desired test functionality. This will mean including the header files required for your specific tests, adding new tests (each with an individual name) and putting the logic for the setup, running the code to be tested and verifying that it behaves as expected.
If additional library dependencies are required, they should also be added to the CMakeLists after the LINKLIBS
as shown above.
Tests can be run via make tests
, after which you will find the binary in build/px4_sitl_test/unit-MyNewUnit
. It can be run directly in a debugger.
GTest functional tests should be used when the test or the components being tested depend on parameters, uORB messages and/or advanced GTest functionality. Additionally, functional tests can contain local usage of STL data structures (although be careful of platform differences between e.g. macOS and Linux).
The steps to creating new functional tests are as follows:
In general (and similar to unit tests), functional tests should be arranged in three sections: setup, run, check results. Each test should test one very specific behavior or setup case, so if a test fails it is obvious what is wrong. Please try to follow these standards when possible.
Rename the class from ParameterTest to something better representing the code being testing
Add the new file to the directory's CMakeLists.txt
. It should look something like px4_add_functional_gtest(SRC MyNewFunctionalTest.cpp LINKLIBS <library_to_be_tested>)
Add the desired test functionality. This will mean including the header files required for your specific tests, adding new tests (each with an individual name) and putting the logic for the test setup, running the code to be tested and verifying that it behaves as expected.
If additional library dependencies are required, they should also be added to the CMakeLists after the LINKLIBS
as shown above.
SITL unit tests should be used when you specifically need all of the flight controller components - drivers, time, and more. These tests are slower to run (1s+ for each new module), and harder to debug, so in general they should only be used when necessary.
The steps to create new SITL unit tests are as follows:
Within test_[description].cpp include the base unittest-class <unit_test.h>
and all files required to write a test for the new feature.
Within test_[description].cpp create a class [Description]Test
that inherits from UnitTest
.
Within [Description]Test
class declare the public method virtual bool run_tests()
.
Within [Description]Test
class declare all private methods required to test the feature in question (test1()
, test2()
,...).
Within test_[description].cpp implement the run_tests()
method where each test[1,2,...] will be run.
Within test_[description].cpp, implement the various tests.
At the bottom within test_[description].cpp declare the test.
Here is a template:
OPTION
can be OPT_NOALLTEST
,OPT_NOJIGTEST
or 0
and is considered if within px4 shell one of the two commands are called:
or
If a test has option OPT_NOALLTEST
, then that test will be excluded when calling tests all
. The same is true for OPT_NOJITEST
when command test jig
is called. Option 0
means that the test is never excluded, which is what most developer want to use.
Run the complete list of GTest Unit Tests, GTest Functional Tests and SITL Unit Tests right from bash:
The individual GTest test binaries are in the build/px4_sitl_test/
directory, and can be run directly in most IDEs' debugger.
Filter to run only a subset of tests using a regular expression for the ctest name with this command:
For example:
make tests TESTFILTER=unit
only run GTest unit tests
make tests TESTFILTER=sitl
only run simulation tests
make tests TESTFILTER=Attitude
only run the AttitudeControl
test
Copy and rename the example functional test to the directory the code to be tested is in.
Tests can be run via make tests
, after which you will find the binary in build/px4_sitl_test/functional-MyNewFunctional
. It can be run directly in a debugger, however be careful to only run one test per executable invocation using the arguments, as some parts of the uORB and parameter libraries don't clean themselves up perfectly and may result in undefined behavior if set up multiple times.
Examine the sample .
Create a new .cpp file within with name test_[description].cpp.
Note that ut_[name of one of the unit test functions]
corresponds to one of the unittest functions defined within .
Within define the new test:
Within add description name, test function and option:
Add the test test_[description].cpp
to the .