Better Tests

[mikepurvis]

The current tests are very basic. Given that a major feature of this library is timing control, there could be tests which set specific timeout configurations of the read and write timeouts and feed bytes in particular ways to trigger or not-trigger those timeouts. Each one could run nnn trials, to increase the likelihood of hitting weird bugs with timer wraparounds, etc.

Also, since we're talking a lot about what's efficient or not efficient, there could also be some tests which mimic real-world usages, things like "read 10000 bytes of data which arrive one byte at a time", "read 12-byte chunks of data which arrives 24 bytes every 10ms", "read \n-terminated ascii strings at 5Hz", etc. These tests could use clock() to measure approximate CPU usage, and be checked against set ceilings to catch regressions (or improvements) when changes are made.

[wjwwood]

Yeah, more comprehensive tests would be good. Performance tests tend to be tricky, especially with asynchronous activities like this, but they would definitely be useful.

There is also some lower hanging fruit in the form of unit tests for parts of the code which can be decoupled from the read, write, and ioctl calls.