[Cel Skeggs]

Originally Posted by SoftwareBug2.0

It's actually not that hard to put together robot code that is ammenable to this sort of analysis. In our code this year any function that used time took a variable that contained the current time, so time wasn't a problem. And we had a single structure that held almost all of our program's state, so running from arbitrary states was easy too.

Here are the only things that weren't totally clean:
1) We used the filesystem: Our shooter's speed presets depended on a config file, so if you wanted it to work the same every time you needed to start with the same config file. This was easy to deal with in practice; we would just delete the file and let it get recreated.
2) Some data about the current state of the jags wasn't kept with the other program state. This state was never available to the rest of the program so it wasn't an issue when trying to test the other pieces.

This year we made our pieces truely independent of the underlying system, and it meant that we could get great test coverage. It's not that hard.

Yes, it's not all that hard. Most of the CCRE's systems do go through a replaceable abstraction layer. However, all of these cases involve functionality where it will be obvious if you try to go around it. (For example, it won't compile on the actual robot.) Unfortunately, System.currentTimeMillis() isn't like this. I can easily make a replaceable timing system, but then built-in timing systems cannot be used (like System.currentTimeMillis(), java.util.Timer, the WPILib Timer, Thread.sleep, Object.wait, and probably a bunch more.)

The key part here is that since I'm writing a large framework for more people to use than just me or others on my team, I want to avoid forcing this kind of change in user programs.

My current best idea is implementing a class transformer in the emulator that substitutes timing-related calls with abstracted calls. This makes a more complex implementation, but would be less complex for the user. The false implementations could have an auto-time-skip system, so that whenever no threads are ready to run, it fast-forwards until the next sleep or wait times out and then continues on. This would let it run at maximum simulation speed by eliminating the delays from the system, without actually making the program run in a different fashion, and therefore wouldn't limit the usefulness of the framework.