On 26.01.2013 07:34, Laszlo Papp wrote: > > Good question; we discussed this issue before. This is unfortunately also a > real problem for us to test the module with > all the combinations for each factor. It requires (semi-)manual testing and > hence a bit of effort. I see two ways to > improve the automated test coverage: > > * I requested the QtMock module in April for a playground initiation to > extend the test capability of the Qt Project for > such cases like this, but I did not get around to it, unfortunately, to get > anything done for that yet.
For ideal testing a mock would be good which simulates the complete serial port. Is there a interface in front of the native calls which could be implemented by a mock and could be used as a drop in for the real serial port? And it would also be very helpful when there is a recorder which listens to a real serial communication and writes it down, so it can be used later as input for the mock. It's not necessary to have such things now, but the internal interfaces should make it possible to implement it later. Such a mock is sometimes the only way to test error cases which are often hard to reproduce on real hardware. > > * The CI machines could be using a loopback cable, and test it that way. It > would be even better to use a pandaboard or > raspberry pi (with gserial in that case). The board could be used for > receiving and sending data back for instance, but > this requires a special hardware setup. > > Perhaps, there are other alternatives to address this, but these have just > come to my mind for the moment. > > Laszlo > > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
