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.
Best Answer
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.