Hello Developer!

In the last years, unit testing has become more popular in a lot of programming languages. It’s a very useful practice to any kind of program or project. The problem is “How do I start testing?”. If you have already a project that has not being tested from it’s beginning, it becomes hard to start, but not impossible!

Unit testing requires some practices from the developer. If you want to follow the TDD (Test Driven Development), you have to create your tests before coding the logic of your functions and methods. Unit testing is a way to test small parts of a project, in order to help you integrating all of them, or even understand why the whole project is not working the way you expected.

In this post, you’ll see a simple example of unit testing using C++, for a very simple ROS Package. The logic itself is not meaningful in a robotic application, but the configuration of the class and the unit testing is valuable for using in other projects. So, let’s start!

What is this about?

Let’s suppose we need a node that publishes just one topic, called here topic_name. Our node has to publish it every 1 second, but we have class which changes the value we are publishing. So, this class has a very specific behavior to change the message value. This behavior can be anything you want: Calculating the necessary steering for a car, the desired RPY angles for a drone, etc. Here, we are going to create just a method called doSomeMath.

All files described in this post can be found in this repository: https://bitbucket.org/marcoarruda/ros_gtest/src

Creating the class files

Before any file, let’s create a package. For this post, It was created using the following command:
catkin_create_pkg testing roscpp std_msgs

Let’s start with our header file (testing/include/testing/talker.h):

We have some methods: doSomeMath, talk; and attributes: nh_ and pub_.

Now, the cpp file, that implements each method logic (testing/src/talker.cpp):

Great, our class is done! It’s not doing anything special, we have more definitions than logic. Let’s keep it that way, for instance.

Unit Testing Configuration

Now, let’s go to the Unit Testing configuration. We have to follow some conventions, from ROS and GTest. Let’s start creating the necessary files:

 

• testing/tests/tests_1.cpp

 

 

• testing/launch/gtest.test

 

And, finally, let’s make everything well configured in our CMakeLists.txt (testing/CMakeLists.txt):

At this point, your directory should be like this:

Let’s Test it!!

You may have noticed we didn’t create any nodes, yet! The important, for instance, is to test our class.
According to TDD, we have to test before developing. In other words, our tests have to describe what we are expecting from our class, then we implement!

Let’s say we want our doSomeMath method to follow the logic below:
We have a parameter, value, and doSomeMath must return value+5.
But, if the result is higher than 50, it will return 0.

This is exactly what is described between the lines 18 and 32 of the tests_1.cpp file.

Now, we should run the tests. In order to do it in the ROS way, execute the following commands:
catkin_make
catkin_make run_tests

If everything went fine, you should got ERRORS!

That’s ok, we were expecting those errors. After all, we didn’t implement the logic in our method, just wrote some methods to test it.
Now, let’s code the expected behavior in our class! You can code it the way you want. I did the following (testing/src/talker.cpp):

Save the file, compile (catkin_make run_tests command doesn’t compile the code) and run the tests again:
catkin_make
catkin_make run_tests

If everything is correct, you should see something like:

Well, that’s the goal of Unit Testing. The developer has to keep in mind what is expected of a given method or function, describe it in a test suite, run the tests, see it failing and implement the code until the tests pass.