need help writing tests for specific event orderings

[Pekka Paalanen]

On Tue, 3 Oct 2023 14:46:14 -0400
jleivent <jleivent at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20231004/a2cf3ecd/attachment.sig>