Challenge problem: 'ladder of abstraction' iterative design in FRC

[SoftwareBug2.0]

Originally Posted by Colby Skeggs

If you try to abstract out time, you'd really have to run the entire program through (in 1:1 time) and record the results, as resuming from arbitrary states in complex robot code... probably would be extremely complicated to do. If you tried to speed this up, then the program could very easily "break the abstraction" (intentionally or not) and reference System.currentTimeMillis() (or the equivalent call in C++) which would cause different behavior unless you managed to figure out every single hole like that in the system.

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.