osrf_testing_tools_cpp Repository

This repository contains testing tools for C++, and is used in OSRF projects.

osrf_testing_tools_cpp

The osrf_testing_tools_cpp folder is where all the actually useful code lives within a cmake project of the same name.

Any CMake based project can use osrf_testing_tools_cpp by using CMake’s find_package() and then using the various CMake macros, C++ headers and libraries, and other tools as described below.

This package requires C++11 only, but should also work with C++14 and C++17.

Contents

There are several useful components in the osrf_testing_tools_cpp project, and they’re briefly described below.

Googletest

There are a few CMake macros which can provide access to one of a few versions of googletest so that it can be used within your own projects without having to include a copy in each of them.

Example

include(CTest)
if(BUILD_TESTING)
  find_package(osrf_testing_tools_cpp REQUIRED)
  osrf_testing_tools_cpp_require_googletest(VERSION_GTE 1.8)  # ensures target gtest_main exists

  add_executable(my_gtest ...)
  target_link_libraries(my_gtest gtest_main ...)
endif()

You can also list the available versions with osrf_testing_tools_cpp_get_googletest_versions().

This provides access to both “gtest” and “gmock” headers.

add_test with Environment Variables

There is a CMake macro osrf_testing_tools_cpp_add_test() which acts much like CMake/CTest’s add_test() macro, but also has some additional arguments ENV, APPEND_ENV (for PATH-like environment variables), and an OS agnostic APPEND_LIBRARY_DIRS.

This is accomplished with an executable (writtin in C++) which gets put in from of your test executable with additional arguments for any environment variable changes you desire. This “test runner” executable modifies the environment and then executes your test command as specified.

Example

osrf_testing_tools_cpp_add_test(test_my_executable
  COMMAND "$<TARGET_FILE:my_executable>" arg1 --arg2
  ENV FOO=bar
  APPEND_ENV PATH=/some/additional/path/bin
  APPEND_LIBRARY_DIRS /some/additional/library/path
)

This might result in CTest output something like this (this example output is from macOS, hence the DYLD_LIBRARY_PATH versus LD_LIBRARY_PATH on Linux or PATH on Windows):

test 1
    Start 1: test_my_executable

1: Test command: /some/path/install/osrf_testing_tools_cpp/lib/osrf_testing_tools_cpp/test_runner "--env" "FOO=bar" "--append-env" "PATH=/some/additional/path/bin" "DYLD_LIBRARY_PATH=/some/additional/library/path" "--" "/some/path/$
build/my_cmake_project/test_example_memory_tools_gtest" "arg1" "--arg2"

memory_tools

This API lets you intercept calls to dynamic memory calls like malloc and free, and provides some convenience functions for differentiating between expected and unexpected calls to dynamic memory functions.

Right now it only works on Linux and macOS.

Example Test

Here’s a simple, googletest based example of how it is used:

```c++ #include #include

#include <gtest/gtest.h> #include <gtest/gtest-spi.h>

#include “osrf_testing_tools_cpp/memory_tools/memory_tools.hpp” #include “osrf_testing_tools_cpp/scope_exit.hpp”

void my_first_function() { void * some_memory = std::malloc(1024); // .. do something with it std::free(some_memory); }

int my_second_function(int a, int b) { return a + b; }

TEST(TestMemoryTools, test_example) { // you must initialize memory tools, but uninitialization is optional osrf_testing_tools_cpp::memory_tools::initialize();

File truncated at 100 lines see the full file