On Mon, 25 Mar 2024 at 06:19, Thomas Huth <th...@redhat.com> wrote: > We are now using timeouts from the meson test harneess in meson.build, too, > see the slow_qtests[] at the beginning of that file. > You seem to be using a 10 minutes timeout in your test below > (usart_wait_for_flag() function), but you didn't adjust the meson timeout > setting in meson.build, so this does not quite match... > How long does your test take on a very loaded machine (with --enable-debug > used)? If it could take more than 30 seconds, you need to adjust the timeout > in meson.build, too. If it is running very fast, you should likely adjust > the 10 minutes timeout in usart_wait_for_flag() to < 30 seconds instead to > match the meson timeout setting.
I'd forgotten about the meson harness timeout. tests/qtest/microbit-test.c also has a 10 minute timeout but isn't listed as a "slow qtest" (that's the pattern I suggested Arnaud follow for this test). If the meson test harness now handles timeouts, should we write this kind of test to not have a timeout at all, so it simply waits indefinitely for the UART to become ready after writing data to the socket connected to the chardev? Or are there scenarios where the test gets run but not via the meson harness and where we would want to still have a timeout? (For running the test executable by hand for debugging I think hanging indefinitely is fine and arguably more helpful than timing out and stopping.) thanks -- PMM
