ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

How to link tests but not executables in a ROS package?

asked 2011-04-25 23:59:37 -0600

Julius gravatar image

updated 2014-01-28 17:09:35 -0600

ngrennan gravatar image

I am using Google Test Framework for running tests for my ROS package. I compile and link my test executable using

make tests

and run the tests by issuing command

make test

It happens, though, that other executables in that package are linked as well. Since I am usually developing test first and then adapting the source to fit that test, it is very annoying to wait for a long time for linking targets that are not required for running the test.

I do not want to hack the build system (view $(rospack find mk)/, this being inadequate and downright dangerous. Any ideas or option I have overlooked to build only the executable added with rosbuild_add_gtest?

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2011-04-27 03:31:38 -0600

Brian Gerkey gravatar image

There's no way to do this currently, and I don't think it'll be worthwhile to implement it. In your situation, I would do one of two things:

  • comment out the executables from CMakeLists.txt during test development; or
  • put tests in a separate package (e.g., for package foo, put tests in test_foo).

Btw, it's awesome that you're putting such effort into writing tests!


The test target can run two kinds of tests: unit tests (C++ or Python) and rostests. Unit tests, which it sounds like you're using, are generally self-contained (but not always; see below). On the other hand, it's common to use a rostest to verify the functionality of executables that are built by the package (e.g., see test for topic_tools/relay).

To support your use case, we'd need to define two categories of tests: one that wants all the executables built, and one that doesn't, with API hooks to allow the developer to say which kind of test is being declared. We'd further have to segregate libraries from executables, to allow them to be built separately (they're currently both attached to the ALL target). And then we'd likely have to retrofit existing packages that use unit tests to verify executables via fork/exec (e.g., see the pyunit-based rospack test suite).

edit flag offensive delete link more

answered 2011-04-26 00:27:10 -0600

Julius gravatar image

My current workaround is to duplicate CMakeLists.txt, leaving all but the test executable and then taking either one for linking test and other build executables. It's nasty though and it might sometimes happen that your original CMakeLists.txt gets lost when stopping the script in the middle of the build process.

#!/usr/bin/env bash

cp CMakeLists.txt CMakeLists.txt.backup
cp CMakeListsTest.txt CMakeLists.txt

if [ "$1" = "tests" ]; then
    make tests
elif [ "$1" = "test" ]; then
    make test
    cat <<HELP
Usage: test.bash TARGET
Available targets:
    tests -- compile and link tests
    test  -- run tests

mv CMakeLists.txt.backup CMakeLists.txt

Hope this answer gets voted down soon and replaced by a better solution!

edit flag offensive delete link more

Question Tools



Asked: 2011-04-25 23:59:37 -0600

Seen: 521 times

Last updated: Apr 27 '11