Enable convenient unit testing using googletest on POSIX

[MaEtUgR]

Describe problem solved by the proposed pull request
Part of the description I wrote in #11308

The idea is to enable unit testing for any C++ class of the project with very low overhead. For example if you want to test the class AttitudeControl you:

• Create a file AttitudeControlTest.cpp next to the classes source files
• Add px4_add_gtest(SRC AttitudeControlTest.cpp LINKLIBS AttitudeControl) to the folder's CMakeLists.txt
• Start writing your test e.g. :

#include <gtest/gtest.h>
#include <AttitudeControl.hpp>

TEST(AttitudeControlTest, AllZeroCase) {
AttitudeControl attitude_control;
matrix::Vector3f rate_setpoint = attitude_control.update(matrix::Quatf(), matrix::Quatf(), 0.f);
EXPECT_EQ(rate_setpoint(0), 0.f);
}

When you run make unit_test you get the following output (runs all the unit tests):

And it neither needs to rebuild all the libraries you want to test if you're using px4_sitl_default anyways nor does gtest need to be loaded when you're not unit testing with it thanks to #11533

Describe your preferred solution
A clear and concise description of what you have implemented.

Additional context

• Fix Cygwin CMake Build google/googletest#2101 was necessary such that the global gtest configuration builds under Cygwin.
• A future goal is to be able to run all those test also on the targets.

Test data / coverage
Developed and tested on Cygwin Windows toolchain, I will also test on Ubuntu.

[dagar]

I think I'm missing why this has to be done at configure time like this.

[MaEtUgR]

Because otherwise you don't have the CMakeLists-tree of gtest at configure time and can't configure the dependencies correctly.
I see two options around it:

• You have the source anyways because you add it as a submodule but since all submodules have to be present at anytime I prefered the download only if it's actually needed.
• You hack around and achieve that cmake only needs to configure the dependencies to gtest on build time but I didn't achieve that because you need to wrap it and make assumptions about the structure of gtest. It's easy to screw up the include directories and other things this way.

We can still revisit, this is the first state I find acceptable.

[MaEtUgR]

btw the method for the download at configure time is the one from the docs, see last point and following description here https://github.com/google/googletest/blob/master/googletest/README.md#incorporating-into-an-existing-cmake-project

[dagar]

Can the existing cmake testing facilities be used directly?

enable_testing() - https://cmake.org/cmake/help/v3.8/command/enable_testing.html?highlight=i
Then you can check BUILD_TESTING .https://github.com/PX4/Firmware/blob/d42bb01e0ca83813f1d8a96576c6fb9244bb7a19/platforms/posix/CMakeLists.txt#L117

[MaEtUgR]

I found out about the concept and wanted to do that but they are used already for the SITL integration tests. I'd like to be able to run the tests separately since the SITL tests take so much longer. I planned to have a structured test name and use ctest -R to filter the correct ones. So you think distinguishing build time doesn't make sense? I could agree with that. Then gtest is always needed for tests in general and it all depends on BUILD_TESTING.

[MaEtUgR]

Ah and testing is always enabled for sitl... https://github.com/PX4/Firmware/blob/fc7c7ac20630951b17e8644ccc175b9c4e743409/CMakeLists.txt#L303-L305
Can I make it optional?

[dagar]

since the SITL tests take so much longer

Are you talking about the SITL unit tests? Each is roughly 1-3 seconds.
Example: http://ci.px4.io:8080/blue/organizations/jenkins/PX4%2FFirmware/detail/master/722/pipeline/21

[MaEtUgR]

Yes, I expected the basic tests to run two order of magnitudes faster. Is that impatient? 😇 I think it's just starting the simulator binary that takes the big part of that time, otherwise the smallest tests would not all have around the same duration.
Anyways I think we should allow to run the unit tests separately since I presume they'll finish a lot faster until we write a crazy amount of tests or huge loops.

[MaEtUgR]

I'll just add all tests and the gtest library fetching with enable_testing() and hence BUILD_TESTING but make enabling tests optional for posix. Then I can still filter the tests if I only want to run the quick unit tests e.g. with make tests unit.

[MaEtUgR]

rebased after merging #11308

[MaEtUgR]

Rebased and started to enable the unit test framework with camkes BUILD_TESTING after the comment here: #11573 (comment) Next up is filtering for the different tests such that it's possible to specify what test you want to run for local test-driven development and to exclude WIP tests in CI.

[mcsauder]

@MaEtUgR , Its not clear to me how to build/run the tests with your latest commit, could you clue me in? :)

Your previous commit and others before it run great on Ubuntu 18.10:

[MaEtUgR]

@mcsauder Sorry the latest commit at the time you wrote your comment was an unfinished temporary dump of ongoing tests that's why the commit message started with TEMP:. It ran certain tests double when commanding make tests. I rebased and replaced it over the weekend to add the possibility to filter tests with make tests TESTFILTER=unit. I still need to clean up the unit_test make target because it will get obsolete with one test target and filtering.

[MaEtUgR]

I rebased again. Since I would now start writing useful unit tests I would say this pr is ready for review. One thing I already noticed is the license text is not in every file, I'll fix that quickly.

[MaEtUgR]

@dagar Any chance to get the test framework in? I'm willing to continue to work on how it's embedded in cmake but would appreciate if I was able to start to write unit tests without blowing up this PR. The tests are now included in make tests, built and executed in the poisx_sitl_test folder and are hence checked in CI.

[RomanBapst]

This is quite useful!

[mcsauder]

Nice work @MaEtUgR !

[MaEtUgR]

@dagar rebased on rc1 to run CI again