I’m starting to write C++ code to run a robot, and I don’t know how to incorporate unit testing, if indeed I can. I have been provided with a library which allows the creation of “commands” for the robot, which are automatically scheduled and executed. The mechanism to create these commands is to subclass a command base class they provide, and implement virtual void Initialize(), void Execute(), and void End() methods. These functions are run purely for their side effects, which do things to the robot (run motors, extend pistons, etc.). Because of this, I don’t really see anywhere to attach unit tests to the code, short of mocking the entire library so that I can check the virtual before and after states of the robot. Is there a way to unit test this that isn’t overly burdensome?
Edit
I think I may have been misleading about the functionality of the library. The library provides most of the interface to the robot as well as the command/scheduling system, so it’s not as simple as mocking the command base class, I’d have to mock the entire interface to the hardware. I unfortunately just don’t have the time to do that.
3
What I would do in this case would be to introduce my own RobotControl interface with methods corresponding to the ones in the real lib.
After having done this, I would make a RobotControlImpl class which implements this interface against the real robot lib.
The commands that I consequently would write would not extend the base class, but instead operate on the interface that you introduced.
This way you can mock RobotControl, pass the mock to any command and verify that it called the right methods on the interface.
In prod you would pass the real impl of RobotControl to the commands that you implemented.
Im not sure if this is what you had in mind and considered cumbersome?
Edit:
Oh, and if you expect the commands to sleep in order to wait for completion (nightmare, but sometimes this is what you have), I would require the commands to call a sleep method on RobotControl. This way you can disable sleeps during test and just verify that the command tries to sleep.
2
I think is possible to make the code testable in a minimally invasive way. By that I mean by that is that you can write the commands exactly as intended by the robot library authors. This can be advantageous if you want to exchange code with others that are not using your intermediate layer.
It does require a separate “unit test build” of your code.
What you do is that in one central header file, you check a compile time define if this is the unit test build, and if so, redefines the name of the base class, and maybe some other classes in the robot library to names of classes of your test implementation. You should define the same virtual functions as in the robot lib, as well as provide stubs for methods you invoke on the robot.
Then you have commands that you can throw in your own testing framework that invokes the same methods the robot library would do.
This will involve some amount of stubbing and mocking, but that is inevitable in any unit test design.
Changing the base class name could be done with a #define or probably preferred, a typedef.