Rtest

This repository provides a suite of tools and utilities tailored for testing and debugging ROS 2 (Robot Operating System) applications. It aims to simplify the development and testing workflows for ROS 2-based projects, particularly in scenarios involving unit and integration testing.

The tools in this repository address challenges posed by ROS 2’s inter-process communication, which can lead to inconsistent test results. By focusing on integration testing without revalidating the underlying RMW (ROS Middleware) implementations, this repository ensures a more streamlined and reliable testing process.

This framework enables writing reliable, fully repeatable unit tests (and more) for C++ ROS 2 implementations, eliminating the issue of so-called “flaky tests”.

Contributors

This repository and tooling was initally developed as a collaboration between BEAM and Spyrosoft; and is maintained as a collaboration.

Features

• Verifying whether the tested Node has created the necessary entities such as publishers, subscribers, timers, services clients, services providers, action servers or action clients.
• Setting expectations on mocked entities, enabling verification of events such as publishing expected messages on a selected topic, sending a request by a client or validating a service response, sending action goals or verifying action feedback and results.
• Direct message passing to subscribers, or direct request injection to services and responding to clients.
• Direct timer callbacks firing and simulated time control, resulting in immediate and precise time-dependent implementations testing.
• Single-threaded, controllable test execution.

LIMITATION: The rtest framework has a significant limitation, in order to test the implementation against ROS 2, access to the source code of those components is required. They need to be directly included in the test build process. For example: testing interactions with components coming from external dependencies, such as those installed from system repositories, is not possible. In such cases, the source code of those packages must be downloaded and included in the workspace source tree.

Documentation

Complete documentation: Rtest Documentation

Requirements

• rclcpp
• GoogleTest
• ament_cmake_ros

Quick-Start

1. Clone the repository:

    $ git clone https://github.com/yourusername/rtest.git
    

1. Build and run the test examples:

    $ colcon build --cmake-args="-DRTEST_BUILD_EXAMPLES=On"
    $ colcon test --packages-select rtest_examples --event-handlers console_cohesion+
    

Adding Testing Support to Your Package

1. Add Dependencies

Add a dependency to rtest in your package.xml file:

<package format="3">
  ...
  <test_depend>rtest</test_depend>
</package>

2. Create Test Directory

Create a sub-folder test and add a CMakeLists.txt file there.

WARNING: The Rtest uses C++ template code substitution at the source level. You must build the unit under test directly from sources. Linking with a static or dynamic library will not work.

Example CMakeLists.txt:

find_package(ament_cmake_gmock REQUIRED)
find_package(rtest REQUIRED)

ament_add_gmock(${PROJECT_NAME}-test
  main.cpp
  unit_tests.cpp
  ${CMAKE_SOURCE_DIR}/src/ros2_node.cpp
)

target_link_libraries(${PROJECT_NAME}-test
  rtest::publisher_mock
  rtest::subscription_mock
  rtest::timer_mock
  rtest::service_mock
  rtest::service_client_mock
  rtest::action_server_mock
  rtest::action_client_mock
)

target_link_libraries(${PROJECT_NAME}-test
  rclcpp::rclcpp
)

3. Create Test Main File

File truncated at 100 lines see the full file

Contributing Guidelines

Thank you for your interest in contributing to rtest. Whether it’s a bug report, new feature, correction, or additional documentation, we greatly value feedback and contributions from our community.

Please read through this document before submitting any issues or pull requests to ensure we have all the necessary information to effectively respond to your bug report or contribution.

Reporting Bugs/Feature Requests

We welcome you to use the GitHub issue tracker to report bugs or suggest features.

When filing an issue, please check existing open, or recently closed, issues to make sure somebody else hasn’t already reported the issue. Please try to include as much information as you can. Details like these are incredibly useful:

• A reproducible test case or series of steps
• The version of our code being used
• Any modifications you’ve made relevant to the bug
• Anything unusual about your environment or deployment

Contributing via Pull Requests

Contributions via pull requests are much appreciated. Before sending us a pull request, please ensure that:

1. Limited scope. Your PR should do one thing or one set of things. Avoid adding “random fixes” to PRs. Put those on separate PRs.
2. Give your PR a descriptive title. Add a short summary, if required.
3. Make sure the pipeline is green.
4. Don’t be afraid to request reviews from maintainers.
5. New code = new tests. If you are adding new functionality, always make sure to add some tests exercising the code and serving as live documentation of your original intention.

To send us a pull request, please:

1. Fork the repository.
2. Modify the source; please focus on the specific change you are contributing. If you also reformat all the code, it will be hard for us to focus on your change.
3. Ensure local tests pass. (colcon test )
4. Commit to your fork using clear commit messages.
5. Send a pull request, answering any default questions in the pull request interface.
6. Pay attention to any automated CI failures reported in the pull request, and stay involved in the conversation.

GitHub provides additional documentation on forking a repository and creating a pull request.

Signed-off commits

Contributors must sign-off each commit by adding a Signed-off-by: ... line to commit messages to certify that they have the right to submit the code they are contributing to the project according to the Developer Certificate of Origin (DCO).

Finding contributions to work on

Looking at the existing issues is a great way to find something to contribute on. As this project, by default, uses the default GitHub issue labels (enhancement/bug/duplicate/help wanted/invalid/question/wontfix), looking at any ‘help wanted’ issues is a great place to start.

Licensing

Any contribution that you make to this repository will be under the Apache 2 License, as dictated by that license:

5. Submission of Contributions. Unless You explicitly state otherwise,
   any Contribution intentionally submitted for inclusion in the Work
   by You to the Licensor shall be under the terms and conditions of
   this License, without any additional terms or conditions.
   Notwithstanding the above, nothing herein shall supersede or modify
   the terms of any separate license agreement you may have executed
   with Licensor regarding such Contributions.