On Fri, 22 Jan 2016, Alexandre Julliard wrote:
Francois Gouget fgouget@codeweavers.com writes:
On Fri, 22 Jan 2016, Alexandre Julliard wrote:
Why is that better than always printing it in the failing calls?
Because usually there is more than one failing call: there's the ok() after the shell_execute() and then multiple okChildXxx() calls to verify the data received by the child and there is often multiple failures. There is no reason for each of them to repeat the information about what ShellExecute() call failed. By comparing shell_call and last_shell_call okShell ensures that information is printed once before the series of failing tests.
OTOH, it means that in silent mode you get no indication at all.
??? That's what we want right?
We don't want tests that succeed to spew out thousands of lines of traces because that would just bloat the logs, causing them to be rejected by test.winehq.org.
Given that the checks are not supposed to fail, I'm not sure that improving the output for multiple failures is that important.
Sure as long as you never add any new test and only run it on platforms where there are no failures then you don't get any failures and failure logging does not matter one bit.
But the ShellExecute() tests are very incomplete and I'm adding a bunch of new ones. And that's much easier to do if I get useful logs when the new test I add fails because Windows does not behave the way I expect.
Besides, even if we never add any new test we will get failures. All it takes is a new Windows version like Windows 10.