Quote:
Originally Posted by Peter Mitrano
That said, I still think even testing "is my motor spinning" is a huge improvement over what most teams do (no testing at all).
|
Absolutely. This is the huge value of a easy to use simulator, and it allows our programming team to reliably create code before the robot is done and after it's in the bag.
In python, it's far more important to do off-robot testing because it's a dynamic language -- there's a large risk of crashing due to misspelled variables, etc. Because of this we've had excellent test/simulation support for several years now. In the course of development for the pyfrc simulator/test harness, we have a set of 'default' tests that just do the following things:
- Run autonomous mode (with support for running multiple modes)
- Run teleop mode
- Run a 'full match'
- Run a 'full match' with a monkey bashing on the controls randomly
And this meets the needs for most of our robot code -- eg, make sure it doesn't crash due to misspelling of a variable name.
However, we've found there is *some* value in junit-style tests -- but usually we only go to the trouble of writing those when you've got a complex state machine that you want to make sure deals with the edge cases correctly.