Whether it's code review or unit tests, code quality takes time. It isn't free, simple or void of errors. They're only as good as the person behind them. With that said...
Considering that a large portion of robot code is mathematic, it's easy to simulate the error and boundary conditions using loops over a range, and a null or two. Some of the rest of the code is pure logic based upon binary flags: read a button input, if 1 do X, if 0 do Y. Unit tests would set the initial conditions, call specific methods, and test the results.
Architecturally (and security-wise, but that's outside FRC) the worst part about unit tests are ensuring that all method/variable declarations are package-privileged so static unit test classes may call them without needing to modify the original source for variable injection.
The code base for a simple FRC robot is small enough that any unit tests would suffice without tools. Add vision, speed ramping, etc - it's easy to go straight for something like the Poofs'
Sim-FRC-2015
At work, I've used the pull-request (aka Github) model using Atlassian Stash and another workflow with Gerrit. If Gerrit is used with Jenkins (or any number of other continuous integration setups) then it can automatically kick off a build based upon a code review. Based upon how Gerrit is configured, it can deny merging of the review if the unit tests within Jenkins failed. Also Gerrit used Git's namespacing mechanic to stage the pending changes, then provided a URL in order to fetch & checkout the changes in a local repo. This was insanely useful if someone made changes but then became unavailable to respond to comments. This is what I consider a 'premium' setup and it requires a LOT of time.
I haven't found an equivalent for Stash, other than having unit test results copy-pasted into a pull request. I can pull the changes since I am admin/integrator, but if I didn't have that role I don't know how I could pull the changes to test locally.
With Github, you should be able to get a link to the patchset of a pull request, then you could fetch the change, run the unit test, post results and continue with the merge (or not) from there.