On Tue, 3 Oct 2023 14:46:14 -0400 jleivent <jleiv...@comcast.net> wrote:
> I am trying to write some tests that provoke errors in libwayland, but > it doesn't seem to me like the existing test suite provides a mechanism > to create specific event orderings that are allowed but not guaranteed > by the asynchrony of the protocol. Is that correct? It looks to me > like the tests in the test suite that involve a client and server all > fork the client and allow it and server to run asynchronously without > a way to impose any ordering restriction, but it's hard to tell. If > there is a mechanism to use to get specific event orderings, where is > it? For the forked clients, there is stop_display()/display_resume(). Maybe that helps? > I could simulate one side (the side that doesn't encounter the error) > by directly marshalling the messages it would send into the wire to the > other side. That might be a suitable unit test for after the error is > proven to exist in the field, but it doesn't (conclusively) prove that > the error can exist in the field because of its reliance on simulation > tactics. That's my fallback - but is there a better way? If you limit your direct marshalling to sequences that are theoretically allowed, doesn't that already help you prove that all those cases are handled correctly? It's also useful to test sequences that are theoretically illegal, to ensure they raise the appropriate errors. But I guess your goal is to see if using the API correctly could ever trigger an illegal sequence? I wonder if that's even possible without adding more test hooks inside libwayland. Adding test hooks is possible though, os-wrappers-test.c makes use of some already. It's also possible to call both server and client APIs from the same thread/process on the same Wayland connection, but you need to be careful to prove it cannot deadlock. That should be much easier since it's all single-threaded, and you just need to make sure the fds have data to read and queues have messages to dispatch when you expect them. While it would be bad to do nested dispatch, like client side event handler calling wl_display_dispatch, I believe there should be no problem calling server API from client side handlers and vice versa when everything is single-threaded. Thanks, pq
pgpPZYgn_bCxK.pgp
Description: OpenPGP digital signature
