Create test for GPS_Novatel class to make sure SampleScanner BUFSIZE is greater than 4096

[topher800]

[topher800]

Gary, thoughts on what this test should look like? We removed the custom SampleScanner from GPS_NMEA, so all the GPS classes fall back to CharacterSensor.

Off top of your head do you know when/where SampleScanners get built? The test would need to go after that, so I assume in GPS ctor is too soon....

Should this be in tests/ or should this just be an assert in the code somewhere?

[garyjg]

What if the test ran like src/tests/serial_sensor, where a script starts up a dsm, feeds it Novatel UDP messages, then confirms the correct messages were received? That way you're testing the full path, starting with the UDP socket. You could modify sensor_sim to send sensor data over UDP instead of serial, or just use ncat or whatever. The run_test.sh script already has a function to find available UDP ports, so you wouldn't have to hard code it, although hardcoding it would be an easy place to start. You might be able to source that script, then run similar steps but with a different xml config and a different sensor simulator.

I think there are problems with relying only on assert. As mentioned in #13, it's not always certain that assert() is active on the particular target where you really need it. So if the point is to immediately detect and abort when the full Novatel packet is not being received, because that's a catastrophic problem in production, then I think that should be explicit in the code rather than just a call to assert. Also, assert() does not tell you there's a problem on a target until you run the code on the target, whereas a test gives you a chance to see failures before pushing the release.

I think asserts are meant to be developer-friendly and for development, they are not user-friendly and not for production.

[topher800]

ok, now I see. I was thinking about a test to make sure the BUFSIZE was big enough for the RANGE packet.