[Cel Skeggs]

We have a similar setup - four students who pull-request into master in our GitHub repo.

The primary way that we have people test their code is through our emulator system (looks something like this) and that seems to catch anything really obvious. Beyond that, anything that has slipped through that either gets caught during code-review or gets fixed later once we start running our code on the actual robot - most of the issues we run into tend to be directions or states getting reversed, and those are relatively easy to fix.

In the case of your example: "a command passes in a negative value to drive a motor forward, but the method being called requires a positive value to do that" - simply adding error checking code to the method means that the bug gets uncovered immediately. Then, the code reviewer can just make sure that they have appropriate checks on any new methods, and a significant portion of bugs will get caught.

We haven't used unit testing in our robot code itself, but our framework has quite a few to test its core components. To get this to work, we had to figure out a few of the same things as you'll need for actual testing - notably, we needed a way to mock out the passage of time. So now our unit tests can make the tested components use fake time and change it as necessary. We've tested a number of time-dependent components successfully with this system. We use JUnit for this - see an example of our ExpirationTimer test here.

One strategy which might be useful would be to "record" certain "sessions" of running a robot (in an emulator or on a real robot) and check that the new version of the code plays back the same sequence (or at least a close-enough sequence) when it gets run with the same input data.