[1/2] shell32/tests: Trace the last ShellExecute command whenever a corresponding test fails.

Francois Gouget fgouget at codeweavers.com
Fri Jan 22 06:54:40 CST 2016


On Fri, 22 Jan 2016, Alexandre Julliard wrote:

> Francois Gouget <fgouget at 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.


-- 
Francois Gouget <fgouget at codeweavers.com>



More information about the wine-devel mailing list