Revision history [back]

Moreover, if my node is aimed to control hardware, I usually initialize the communication in the constructor to avoid to start it manually each time. This can be also a problem because it forces me to stay with the device connected while testing (which is ok for higher level testing, but not for unit testing).

This problem can be addressed by using dependency injection on the ROS node level. Assuming you have a single class which implements the hardware interfacing you could e.g. use a ROS parameter to indicate the replacement of the actual hardware interfacing calls in the ROS node construction (compare library level constructor injection) with a test double class (dummy, stub or fake). The test double must have the same production specific API that it is conform to the ROS node's calls. To configure the test double class (e.g. to continuously provide test specific fake sensor data) you have to add test specific class API calls to the ROS node as well e.g. using a test hook means compile time insertion of these additional "test" specific API calls. On the ROS node level the configuration of the test specific test double API calls can be implemented with ROS parameters as well.

Moreover, if my node is aimed to control hardware, I usually initialize the communication in the constructor to avoid to start it manually each time. This can be also a problem because it forces me to stay with the device connected while testing (which is ok for higher level testing, but not for unit testing).

This problem can be addressed by using dependency injection on the ROS node level. Assuming you have a single class which implements the hardware interfacing you could e.g. use a ROS parameter to indicate the replacement of the actual hardware interfacing calls in the ROS node construction (compare library level constructor injection) with a test double class (dummy, stub or fake). The test double must have the same production specific API that it is conform to the ROS node's calls. To configure the test double class (e.g. to continuously provide test specific fake sensor data) you have to add test specific class API calls to the ROS node as well e.g. using a test hook means compile time insertion of these additional "test" specific API calls. On the ROS node level the configuration of the test specific test double API calls can be implemented with ROS parameters as well.