4 ms·
Basic idea: to verify your robot in a quick and harmless way, disconnect its actuators, feed fake data to its sensors, observe its stream of decisions, and veri
by mbrock 8y ago
Basic idea: to verify your robot in a quick and harmless way, disconnect its actuators, feed fake data to its sensors, observe its stream of decisions, and verify that it behaves according to some rules.
If your robot has different parts with their own rules of behavior, then you should be able to detach them to test them on their own, or in a much simpler test harness.
I think the complaints about unit tests often amount to “we’re taking the robot apart into too many parts that actually depend on each other in complex ways, so testing them independently is tedious and gives us little real information.”
Another kind of complaint is “our robot has a huge amount of functions that all interact in very complicated ways and we haven’t specified any overarching principles so our tests are just a lot of arbitrary scripts that we have to change constantly to accomodate the robot’s ever-changing repertoire of fascinating behaviors.”
Or “there is no exhaustive list of our robot’s sensors and actuators, and many of them are complex third party products which we integrate without any adapters, so it’s nearly impossible to take the thing apart and provide a realistic simulated environment.”
I think the underlying complaint is something like “we were told that there was an easy method to make our software correct, and it’s disappointing that it doesn’t work well without considerable investment into domain modeling, architectural work, mathematical analysis, etc.”