Testing in ROS - tsirif/pandora-playground GitHub Wiki

ROS Topics

###2. Testing in ROS

Developing in ROS, which has a particular API that forces clear definitions on the modules of the robotic system in making, means that there are certain particularities in the way testing is made. That is because ROS offers an API that we can trust, so we need not to test it. In addition, ROS is compatible with gtest for C++ and unittest (that's another testing framework) for Python, so whatever is used in general can be used also in ROS.

How to use gtest in ROS: http://wiki.ros.org/gtest
Why is testing important and what you should be careful about: http://wiki.ros.org/UnitTesting

Unit Testing

When unit testing in ROS, you should make your tests ROS agnostic. This means that they should run independently of the platform and the framework and that one should not use any ROS attributes in their unit tests.
You should also declare the tests you make in the CMakeLists.txt of the package which they belong to. You can do so with the CMake macro:
catkin_add_gtest(test_name test_relative_path)
where 'test_name' is the executable test's name (note that it is unique among all executables that are being built simultaneously) and 'test_relative_directory' is the relative path of the test to the CMakeLists.txt path (e.g. test/unit/test_something.cpp).

Functional and Integration Testing

As each node in the system is a separate process, this means that each node is to be treated as an independent piece of software that has well defined inputs and outputs. This means that for each node an appropriate functional test must be written. Because all nodes are communicating and exchanging information using ROS interface, these tests will also reveal how well a developer has implemented the ROS interfaces. In addition, though there exists already the interface itself, there do not exist testing modules on the other end of the communication channel and the input testing info is not ready too. So we must develop mock objects that implement as simply as possible the ROS interface on the other end in order to serve as behavior testers apart from their mocking ability. Integration testing involves the same process of testing. Because the interface does not change the same mocks can be used for functional and integration testing! The only difference is that in integration testing multiple nodes are running as they are forming a connected graph. At this point we simply trust that ROS will successfully deliver the information across the topics (channels) that we do not check. Integration tests continue until all nodes of the system are up and running on one single integration test. In this last system test, simulation or real-life experiments must be utilized because the complexity of the inputs is too damn high.

Simulating Robots

Simulators implement the lowest possible interface level which provides your software with raw info. They are made specifically with this in mind and are also responsible for creating good real-life input data. In other words, you won't be probably able to make better mock objects than a simulator because that's what they are made to be. The most popular simulator, which is ROS compatible, is Gazebo. There is also S.T.D.R. simulator which is developed by members of our team!

• Gazebo: http://wiki.ros.org/gazebo_ros_pkgs
• STDR: http://wiki.ros.org/stdr_simulator

I will soon provide this page with links on how to install these. Also, some simple code and tests for reference and some slightly more complicated piece of code for debugging, testing, refactoring and experimenting upon on your own initiative.