Testability is an essential feature in any GNSS receiver. The companion tutorial Testing the software receiver, Part I: Methodology describes the general approach taken in this project, and this page documents the available set of Unit and System tests. Some of them are highly configurable, so they can be seen as Performance tests.

In order to execute the tests, you must build GNSS-SDR from source. If the Google C++ Testing Framework source code is not already present in your system (and pointing the GTEST_DIR environment variable to the root of the source code tree or, on Debian-based GNU/Linux distributions, doing sudo apt-get install libgtest-dev), it will be automatically downloaded from its Git repository, compiled and linked to GNSS-SDR at building time. The CMake script automates all those steps for you.

Tip: some tests can optionally output plots if Gnuplot, a portable command-line driven graphing utility, is installed in your system. If you want to use this feature, install Gnuplot (by doing sudo apt-get install gnuplot in Debian-based Linux distributions, or sudo port install gnuplot using Macports in macOS) before building GNSS-SDR, and then activate the corresponding flag in the tests in which it is allowed (those flags start with --plot_...). This will display figures in new windows and will save them as PostScript and PDF files in the folder where the test was called. In order to avoid showing plots on the screen, but still get the figures in files, use --noshow_plot.

GNSS-SDR tests are divided into two categories:

• Unit Tests: checking of certain functions and areas - or units - of the source code.
• System Tests: checking conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements.

By default, only a (large) subset of unit tests is compiled (see details below). So, when doing:

$ cd gnss-sdr/build
$ git checkout next
$ cmake ..
$ make
$ make check  # THIS STEP IS OPTIONAL. It builds and runs a subset of tests.

this process will end up generating some executables at the gnss-sdr/install folder. Among them, a test program called run_tests. This executable gathers all the available GNSS-SDR’s unit tests. It can be run by doing:

$ cd ../install
$ ./run_tests

The output of this program should be similar to:

Running GNSS-SDR Tests...
[==========] Running 217 tests from 57 test suites.
[----------] Global test environment set-up.

...

[----------] Global test environment tear-down
[==========] 217 tests from 57 test suites ran. (64845 ms total)
[  PASSED  ] 217 tests.

Other additional unit and system tests require external tools, libraries and data files not included in the GNSS-SDR’s source tree. As in the case of the Google C++ Testing Framework source code, they can be automatically downloaded and built by passing the following option flags to CMake:

Those extra tests are described below.

Tests programs generated with the Google C++ Testing Framework accepts a number of interesting command-line flags. Hereafter we describe some of the most relevant ones.

Using the testing framework

Listing Tests names

Sometimes it is necessary to list the available tests in a program before running them so that a filter may be applied if needed. Including the flag --gtest_list_tests overrides all other flags and lists tests in the following format:

TestSuite1.
  TestCase1
  TestCase2
TestSuite2.
  TestCase

So, running:

$ ./run_tests --gtest_list_tests

will get the currently available unit Test Suites and unit Test Cases.

Running a Subset of the Tests

By default, a Google Test program runs all tests the user has defined. Sometimes, you want to run only a subset of the tests (e.g. for debugging or quickly verifying a change). If you set the GTEST_FILTER environment variable or the --gtest_filter flag to a filter string, Google Test will only run the tests whose full names (in the form of TestSuiteName.TestCaseName) match the filter.

The format of a filter is a ‘:‘-separated list of wildcard patterns (called the positive patterns) optionally followed by a ‘-’ and another ‘:‘-separated pattern list (called the negative patterns). A test matches the filter if and only if it matches any of the positive patterns but does not match any of the negative patterns.

A pattern may contain ‘*’ (matches any string) or ‘?’ (matches any single character). For convenience, the filter ‘*-NegativePatterns’ can be also written as ‘-NegativePatterns’.

For example:

• $ ./run_tests Has no flag, and thus runs all its tests.
• $ ./run_tests --gtest_filter=* Also runs everything, due to the single match-everything * value.
• $ ./run_tests --gtest_filter=GpsL1CaPcpsAcquisitionTest.* Runs everything in test suite GpsL1CaPcpsAcquisitionTest.
• $ ./run_tests --gtest_filter=*Gps*:*Acquisition* Runs any test whose full name contains either “Gps” or “Acquisition”.
• $ ./run_tests --gtest_filter=-*Acquisition* Runs all non-Acquisition tests.
• $ ./run_tests --gtest_filter=GpsL1CaPcpsAcquisitionTest.*-GpsL1CaPcpsAcquisitionTest.ValidationOfResults Runs everything in test suite GpsL1CaPcpsAcquisitionTest except GpsL1CaPcpsAcquisitionTest.ValidationOfResults.

Repeating the Tests

The --gtest_repeat flag allows you to repeat all (or selected) test methods in a program many times.

For example:

$ ./run_tests --gtest_filter=GpsL1CaPcpsAcquisitionTest.* --gtest_repeat=10

executes all the tests in the Test Suite GpsL1CaPcpsAcquisitionTest ten times.

Generating an XML Report

Google Test can emit a detailed XML report to a file in addition to its normal textual output. To generate the XML report, set the GTEST_OUTPUT environment variable or the --gtest_output flag to the string “xml:_path_to_output_file_”, which will create the file at the given location. You can also just use the string “xml”, in which case the output can be found in the test_detail.xml file in the current directory.

If you specify a directory (for example, “xml:output/directory/”), Google Test will create the XML file in that directory, named after the test executable (e.g. run_tests.xml for test program run_tests). If the file already exists (perhaps left over from a previous run), Google Test will pick a different name (e.g. run_tests_1.xml) to avoid overwriting it.

The format of the report is as follows:

<?xml version="1.0" encoding="UTF-8"?>
<testsuites name="AllTests" ...>
  <testsuite name="test_suite_name" ...>
    <testcase name="test_case_name" ...>
      <failure message="..."/>
      <failure message="..."/>
      <failure message="..."/>
    </testcase>
  </testsuite>
</testsuites>

• The root <testsuites> element corresponds to the entire test program.
• <testsuite> elements correspond to Google Test test suites.
• <testcase> elements correspond to Google Test test cases.

For example:

$ ./run_tests --gtest_filter=CpuMulticorrelatorTest.* --gtest_output=xml

generates a report called test_detail.xml in the current directory;

$ ./run_tests --gtest_filter=CpuMulticorrelatorTest.* --gtest_output=xml:./test_results/

generates a report called run_tests.xml in a newly created ./test_results directory; and

$ ./run_tests --gtest_filter=CpuMulticorrelatorTest.* --gtest_output=xml:./test_results/my_tests.xml

generates a report called my_tests.xml in the ./test_results directory.

All these examples produce the following report:

<?xml version="1.0" encoding="UTF-8"?>
<testsuites tests="1" failures="0" disabled="0" errors="0" timestamp="2017-06-25T09:43:52" time="2.365" name="AllTests">
  <testsuite name="CpuMulticorrelatorTest" tests="1" failures="0" disabled="0" errors="0" time="2.365">
    <testcase name="MeasureExecutionTime" status="run" time="2.365" classname="CpuMulticorrelatorTest" />
  </testsuite>
</testsuites>

Description of available tests

Unit Tests

The generation of some unit test suites are enabled by default, and gathered in the test program run_tests.

Unit Test Suites for arithmetics:

• CodeGenerationTest: set of test cases for gnss_signal_replica.h measuring the execution time of various implementations of PRN code generation.
• ComplexCarrierTest: set of test cases for gnss_signal_replica.h measuring the execution time of various implementations of complex carrier generation. The default vector length is \(100000\), but this test suite accepts the flag --size_carrier_test. You can try a different length by doing:

   $ ./run_tests --gtest_filter=ComplexCarrier* --size_carrier_test=1000000
  

• ConjugateTest: set of test cases measuring the execution time of various implementations of vector conjugation. The default vector length is \(100000\), but this test suite accepts the flag --size_conjugate_test. You can try a different length by doing:

   $ ./run_tests --gtest_filter=Conjugate* --size_conjugate_test=1000000
  

• FFTLengthTest: set of test cases measuring the execution time for several FFT lengths. The default number of averaged iterations is \(1000\), but this test suite accepts the flag --fft_iterations_test. If you have Gnuplot installed in your system, you can get some plots by adding the flag --plot_fft_length_test. You can try a different number of iterations and get some plots by doing:

   $ ./run_tests --gtest_filter=FFT* --fft_iterations_test=10000 --plot_fft_length_test
  

• MagnitudeSquaredTest: set of test cases measuring the execution time of various implementations of vector square magnitude computation. The default vector length is \(100000\), but this test suite accepts the flag --size_magnitude_test. You can try a different length by doing:

   $ ./run_tests --gtest_filter=Magnitude* --size_magnitude_test=1000000
  

• MultiplyTest: set of test cases measuring the execution time of various implementations of vector (element-by-element) multiplication. The default vector length is \(10000\), but this test suite accepts the flag --size_multiply_test. You can try a different length by doing:

   $ ./run_tests --gtest_filter=Multiply* --size_multiply_test=100000
  

Unit Test Suites for the control plane:

• ControlThreadTest: set of test cases for control_thread.h
• FileConfigurationTest: set of test cases for file_configuration.h
• GNSSBlockFactoryTest: set of test cases for gnss_block_factory.h
• GNSSFlowgraph: set of test cases for gnss_flowgraph.h
• InMemoryConfiguration: set of test cases for in_memory_configuration.h
• StringConverterTest: set of test cases for string_converter.h

Unit Test Suites for signal processing blocks:

• Signal sources
  • FileSignalSource: set of test cases for file_signal_source.h
  • ValveTest: set of test cases for gnss_sdr_valve.h
  • Unpack2bitSamplesTest: set of test cases for unpack_2bit_samples.h
• Data Type Adapter
  • PassThroughTest: set of test cases for pass_through.h
  • DataTypeAdapter: set of test cases for data type adapters byte_to_short.h, ibyte_to_cbyte.h, ibyte_to_complex.h, ibyte_to_cshort.h, ishort_to_complex.h and ishort_to_cshort.h
• Input filter
  • FirFilterTest: set of test cases for fir_filter.h
• Resampler
  • DirectResamplerConditionerCcTest: set of test cases for direct_resampler_conditioner_cc.h
  • MmseResamplerTest: set of test cases for mmse_resampler_conditioner.h
• Acquisition
  • GpsL1CaPcpsAcquisitionTest: set of test cases for gps_l1_ca_pcps_acquisition.h. If Gnuplot is installed in your machine, this test can plot the acquisition grid by passing the flag --plot_acq_grid. Example:

       $ ./run_tests --gtest_filter=GpsL1CaPcpsAcquisitionTest* --plot_acq_grid
    

  • GpsL1CaPcpsAcquisitionGSoC2013Test: set of test cases for gps_l1_ca_pcps_acquisition.h developed during GSoC 2013.
  • GpsL1CaPcpsTongAcquisitionGSoC2013Test: set of test cases for gps_l1_ca_pcps_tong_acquisition.h
  • GpsL1CaPcpsQuickSyncAcquisitionGSoC2014Test: set of test cases for gps_l1_ca_pcps_quicksync_acquisition.h
  • GalileoE1PcpsAmbiguousAcquisitionTest: set of test cases for galileo_e1_pcps_ambiguous_acquisition.h. If Gnuplot is installed in your machine, this test can plot the acquisition grid by passing the flag --plot_acq_grid. Example:

       $ ./run_tests --gtest_filter=GalileoE1PcpsAmbiguousAcquisitionTest* --plot_acq_grid
    

  • GalileoE1PcpsAmbiguousAcquisitionGSoCTest: set of test cases for galileo_e1_pcps_ambiguous_acquisition.h developed during GSoC 2012.
  • GalileoE1PcpsAmbiguousAcquisitionGSoC2013Test: set of test cases for galileo_e1_pcps_ambiguous_acquisition.h developed during GSoC 2013.
  • GalileoE1PcpsTongAmbiguousAcquisitionGSoC2013Test: set of test cases for galileo_e1_pcps_tong_ambiguous_acquisition.h developed during GSoC 2013.
  • GalileoE1PcpsQuickSyncAmbiguousAcquisitionGSoC2014Test: set of test cases for galileo_e1_pcps_quicksync_ambiguous_acquisition.h developed during GSoC 2014.
  • GalileoE5aPcpsAcquisitionGSoC2014GensourceTest: set of test cases for galileo_e5a_noncoherent_iq_acquisition_caf.h developed during GSoC 2014.
  • GlonassL1CaPcpsAcquisitionGSoC2017Test: set of test cases for glonass_l1_ca_pcps_acquisition.h developed during GSoC 2017.
• Tracking
  • CpuMulticorrelatorTest: set of test cases for cpu_multicorrelator.h that measure the execution time for multi-correlations of size \(2048\), \(4096\) and \(8192\). By default, the measurements average \(1000\) independent realizations, a value that can be changed by the flag --cpu_multicorrelator_iterations_test. You can also set the number of threads spawned by this program with the flag --cpu_multicorrelator_max_threads_test. A possible call for this test could be:

     $ ./run_tests --gtest_filter=Cpu* --cpu_multicorrelator_iterations_test=10000 --cpu_multicorrelator_max_threads_test=2
  

  • GpuMulticorrelatorTest: set of test cases for cuda_multicorrelator.h that measure the execution time for multi-correlations of size \(2048\), \(4096\) and \(8192\) executed in the GPU. The availability of this test suite requires the CUDA Toolkit installed in your system, a GPU supporting CUDA, and have passed the option -DENABLE_CUDA=ON to CMake. By default, the measurements average \(1000\) independent realizations, a value that can be changed by the flag --gpu_multicorrelator_iterations_test. You can also set the number of threads spawned by this program with the flag --gpu_multicorrelator_max_threads_test. A possible call for this test could be:

     $ ./run_tests --gtest_filter=Gpu* --gpu_multicorrelator_iterations_test=10000 --gpu_multicorrelator_max_threads_test=2
  

  • GalileoE1DllPllVemlTrackingInternalTest: set of test cases for galileo_e1_dll_pll_veml_tracking.h
  • GlonassL1CaDllPllTrackingTest: set of test cases for glonass_l1_ca_dll_pll_tracking.h
  • GlonassL1CaDllPllCAidTrackingTest: set of test cases for glonass_l1_ca_dll_pll_c_aid_tracking.h
  • GalileoE5aTrackingTest: set of test cases for galileo_e5a_dll_pll_tracking.h
  • TrackingLoopFilterTest: set of test cases for tracking_loop_filter.h
• Telemetry Decoder
  • Galileo_FNAV_INAV_test: set of test cases for galileo_inav_message.h and galileo_fnav_message.h
• Observables
  • -
• PVT
  • RinexPrinterTest: set of test cases for rinex_printer.h
  • RtcmTest: set of test cases for rtcm.h
  • RtcmPrinterTest: set of test cases for rtcm_printer.h
• System parameters:
  • GlonassGnavEphemerisTest: set of test cases for glonass_gnav_ephemeris.h
  • GlonassGnavNavigationMessageTest: set of test cases for glonass_gnav_navigation_message.h

Extra Unit Tests

This option builds some extra unit test cases that require external tools not included in the GNSS-SDR source tree. It can be activated by:

$ cmake -DENABLE_UNIT_TESTING_EXTRA=ON ..
$ make

This option will download, build and link (at building time) the following tools and files:

• A basic software-defined GNSS signal generator based on gps-sdr-sim and available at https://bitbucket.org/jarribas/gnss-simulator, which includes some sample RINEX and trajectory (.csv) files used by optional tests.

• The GNSSTk project, an open-source library and suite of applications for the satellite navigation community. GNSSTk is sponsored by the Space and Geophysics Laboratory, within the Applied Research Laboratories at the University of Texas at Austin (ARL:UT). GNSSTk is the by-product of GPS research conducted at ARL:UT since before the first satellite launched in 1978; it is the combined effort of many software engineers and scientists. In 2003, the research staff at ARL:UT decided to open-source much of their basic GNSS processing software as the GNSSTk. The source code is currently available from https://github.com/SGL-UT/gnsstk.

• It downloads gps_l2c_m_prn7_5msps.dat and Glonass_L1_CA_SIM_Fs_62Msps_4ms.dat, files containing raw GNSS signal samples that are used by some tests as input data.

The following Unit Test Suites are added to the executable run_tests:

Extra Unit Tests for Acquisition blocks

• GpsL2MPcpsAcquisitionTest: set of test cases for gps_l2_m_pcps_acquisition.h that make use of the gps_l2c_m_prn7_5msps.dat raw sample file downloaded with the ENABLE_UNIT_TESTING_EXTRA=ON option.

• GlonassL1CaPcpsAcquisitionTest: set of test cases for glonass_l1_ca_pcps_acquisition.h that make use of the Glonass_L1_CA_SIM_Fs_62Msps_4ms.dat raw sample file downloaded with the ENABLE_UNIT_TESTING_EXTRA=ON option.

AcquisitionPerformanceTest

This test computes the Receiver Operation Characteristic (ROC), that is, Probability of detection vs Probability of false alarm, generated by an Acquisition block. This test accepts the following flags:

Extra Unit Tests for Tracking blocks

• GpsL1CADllPllTrackingTest: set of test cases for gps_l1_ca_dll_pll_tracking.h that make use of the software-defined signal generator. This test plots the correlators’ outputs with the flag --plot_gps_l1_tracking_test. For long tests, data can be decimated with the flag --plot_decimate. For not showing the plots in the screen, but still get the figures in PDF and PS file formats, use --noshow_plots. Example:

  $ ./run_tests --gtest_filter=GpsL1CADllPllTrackingTest* --plot_gps_l1_tracking_test --plot_decimate=10
  

• GpsL1CAKfTrackingTest: set of test cases for gps_l1_ca_kf_tracking.h that make use of the software-defined signal generator. This test plots the correlators’ outputs with the flag --plot_gps_l1_kf_tracking_test. For long tests, data can be decimated with the flag --plot_decimate. For not showing the plots in the screen, but still get the figures in PDF and PS file formats, use --noshow_plots. Example:

  $ ./run_tests --gtest_filter=GpsL1CAKfTrackingTest* --plot_gps_l1_kf_tracking_test --plot_decimate=10
  

• GpsL2MDllPllTrackingTest: set of test cases for gps_l2_m_dll_pll_tracking.h that make use of the gps_l2c_m_prn7_5msps.dat raw sample file downloaded with the ENABLE_UNIT_TESTING_EXTRA=ON option.

TrackingPullInTest

Tracking pull-in test for several Tracking block implementations. It can make use of the software-defined signal generator to produce GPS L1 CA signals at different CN0 levels and to obtain the true synchronization parameters, or to use an external file with any of the supported GNSS signals. The test performs a two-dimensional sweep of Doppler errors and code delay errors for each CN0 to emulate an imperfect signal acquisition in the pull-in tracking step. The test output is a 2D grid plot showing those combinations of Doppler and Code delay errors that produced a valid tracking (green dots) and those that produced a loss of lock (black dots). The criterium to decide a valid tracking is a correct CRC in the demodulation of the navigation message. Example:

$ ./run_tests --gtest_filter=TrackingPullInTest* --plot_detail_level=0 --duration=4 --CN0_dBHz_start=45 CN0_dBHz_stop=35

This test accepts the following flags:

Extra Unit Tests for Telemetry Decoder blocks

• GpsL1CATelemetryDecoderTest: set of test cases for gps_l1_ca_telemetry_decoder.h that make use of the software-defined signal generator.

Extra Unit Tests for Observables blocks

HybridObservablesTest

Unit test for hybrid_observables.h that makes use of the software-defined signal generator or an external file. This test accepts the following flags:

System Tests

This option builds some extra system test programs that require external tools not included in the GNSS-SDR source tree. It can be activated by:

$ cmake -DENABLE_SYSTEM_TESTING=ON ..
$ make

This option generates the following system test program:

ttff

This test program computes the Time-To-First-Fix (TTFF), as defined here. The TTFF indicator provides a measurement of the time required for a static receiver to provide a valid position fix after the receiver is started. This program accepts the following command-line flags:

For TTFF measurements, it makes sense to use real-life GNSS signals. Just prepare a configuration file according to your hardware setup and pass it to the receiver with the --config_file_ttff file, in the same way that you invoke gnss-sdr with --config_file.

Each TTFF sample is computed as the time interval starting with the invocation of the receiver’s executable and ending with the first valid navigation data point derived from live or simulated satellite signals. The start times of the test samples are not synchronized to any UTC time boundary and they should be randomly spread within the 24 hour UTC day and within the GNSS data collection interval. The program starts the receiver, processes the signal until the first fix, and then annotates the elapsed time, shuts down the receiver, waits for a random number of seconds (from 5 to 30 s), and starts the receiver again. This is done a total of M times, and this number can be controlled by the --num_measurements flag.

So an example of running this test could be:

$ ./ttff --config_file_ttff=my_GPS_rx.conf --num_measurements=50

The results of the experiment are reported as follows:

Extra System Tests

This option builds some extra system test programs that require external tools not included in the GNSS-SDR source tree. It can be activated by:

$ cmake -DENABLE_SYSTEM_TESTING_EXTRA=ON ..
$ make

As in the case of the -DENABLE_UNIT_TESTING_EXTRA=ON, this option will also download, build and link the software-defined GNSS signal generator and the GNSSTk C++ library.

This option generates the following system test program:

position_test

This test program computes metrics of static accuracy and precision. It can use either a software-defined signal generator (GPS L1 only) or accept any other receiver configuration obtaining PVT fixes. It accepts the following command-line flags:

So an example of running this test could be:

$ ./position_test

By default, the program triggers a software-defined GPS L1 C/A signal generator, which takes the default RINEX navigation file (brdc3540.14n, already included in the files automatically downloaded by CMake’s -DENABLE_SYSTEM_TESTING_EXTRA=ON option) and the default reference location (longitude \(30.286502^o\), latitude \(120.032669^o\), height \(100\) m), and generates a RINEX observation file and a raw signal sample file, with a duration of \(100\) s. Then, it triggers the software receiver and processes such raw data file. At the end of the processing, the program reports several metrics for accuracy and precision. Since the generation of the raw samples file only needs to be executed once, the next time you execute this program, the generation can be skipped by:

$ ./position_test --disable_generator

If you have Gnuplot installed in your system, you can get some plots by adding the flag --plot_position_test:

$ ./position_test --plot_position_test

You can use your own configuration file:

$ ./position_test --config_file_ptest=my_GPS_rx.conf --static_position="0.000000,000000,0"

changing “0.000000,000000,0” by your reference longitude, latitude, and height (expressed in WGS-84 coordinates). In case of processing live data, please remember to terminate the receiver execution with key q and then [Enter].

When the software receiver terminates, the program reports accuracy and precision metrics for 2D and 3D positioning, expressed in a local ENU (East-North-Up) reference frame and defined as:

For accuracy measurements, the standard deviation of the error in the three local coordinates (in m) are computed as:

with \(E_{ref}\), \(N_{ref}\) and \(U_{ref}\) are the East, North and Up coordinates of the reference location, respectively.

In case of precision measurements:

where \(\hat{E} = \frac{1}{L}\sum_{l=1}^{L}E[l]\), \(\hat{N} = \frac{1}{L}\sum_{l=1}^{L}N[l]\), and \(\hat{U} = \frac{1}{L}\sum_{l=1}^{L}U[l]\).

How to write a new test

Tests behave very much like system “clients”: unit tests imitate the behavior of a corresponding client-class or classes invoking target class methods, and system tests imitate the user behavior. Thinking about how to test a class before actually writing it helps developers to focus on what really matters and to design better interfaces. In other words, it enforces Design for Testability.

The Google C++ Testing Framework provides an implementation of all those testing concepts described in the TDD process, allowing developers to concentrate on the testing code.

In order to create a new test:

1. Use the TEST() macro to define and name a test case. These are ordinary C++ functions that do not return a value.
2. In this function, along with any valid C++ statements you want to include, use the various Google Test assertions to check values.
3. The test’s result is determined by the assertions; if any assertion in the test fails (either fatally or non-fatally), or if the test crashes, the entire test fails. Otherwise, it succeeds.

TEST(test_suite_name, test_case_name)
{
    ... test body ...
}

An example of this would be:

#include <gtest/gtest.h>  // Include Google Test headers
#include "rtcm.h"         // Include header under test

TEST(RtcmTest, HexToInt)  // RtcmTest is the name of the Test Suite
                          // HexToInt is the name of this Test Case
{
    auto rtcm = std::make_shared<Rtcm>();  
    std::string test1 = "2A";
    long int test1_int = rtcm->hex_to_int(test1);
    long int expected1 = 42;
    EXPECT_EQ(expected1, test1_int);
}

This test constructs an object called rtcm of class Rtcm (defined in rtcm.h) and wraps it into a shared pointer that will deallocate memory at the end of the test. Then, it tests the class member function hex_to_int and evaluates the result in an assertion, checking that the obtained result is actually the expected one.

For more details about the usage of the Google C++ Testing Framework and its available features, please check out its User’s Guide:

• Primer – start here if you are new to googletest.
• Advanced Topics – learn some new tricks.
• Frequently-Asked Questions – maybe your question is answered here.

The existing tests are also a source of examples on how to write tests. Please place your testing code in an adequate folder from the GNSS-SDR source tree:

├── src
│   ├── tests
│   │   ├── CMakeLists.txt
│   │   ├── common-files
│   │   ├── data
│   │   ├── signal_samples
│   │   ├── single_test_main.cc
│   │   ├── system-tests
│   │   ├── test_main.cc
│   │   └── unit-tests
│   │       ├── arithmetic
│   │       ├── control-plane
│   │       └── signal-processing-blocks
│   │           ├── acquisition
│   │           ├── adapter
│   │           ├── filter
│   │           ├── libs
│   │           ├── observables
│   │           ├── pvt
│   │           ├── resampler
│   │           ├── sources
│   │           ├── telemetry_decoder
│   │           └── tracking

Once the test code is written, you need to build and link it against the Google Test library. This process is managed in the file gnss-sdr/src/tests/CMakeLists.txt. You will need to list your new test in the appropriate place in order to include it in the building:

• If your test is a Unit Test, please #include it in the file gnss-sdr/src/tests/test_main.cc and rebuild the source code. It should be getting included in the test program run_tests.

• If your test is a System Test, please modify accordingly the file gnss-sdr/src/tests/CMakeLists.txt to define a new target and then rebuild the source code to get the new executable.

At the end of the building, we should be able to run your new test. In the example provided above, this would be:

$ ./run_tests --gtest_filter=RtcmTest.HexToInt*

with the following output:

Running GNSS-SDR Tests...
Note: Google Test filter = RtcmTest.HexToInt*
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from RtcmTest
[ RUN      ] RtcmTest.HexToInt
[       OK ] RtcmTest.HexToInt (1 ms)
[----------] 1 test from RtcmTest (1 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (2 ms total)
[  PASSED  ] 1 test.

Happy testing!