kernel32: Fix a test that fails on all NT platforms

[James Hawkins]

On Tue, Apr 22, 2008 at 1:33 AM, Paul Vriens <paul.vriens.wine at gmail.com> wrote:
> James Hawkins wrote:
>
> >
> > Hi,
> >
> > Changelog:
> > * Fix a test that fails on all NT platforms.
> >
> >  dlls/kernel32/tests/toolhelp.c |   12 +++++++++---
> >  1 files changed, 9 insertions(+), 3 deletions(-)
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> >
>  Hi James,
>
>  I've been looking at some of the patches to fix the tests but I'm a bit
> unsure if some of them are the correct way to go. Things like:
>
>  +    /* win9x does not return a thread, NT does */
>      te.dwSize = sizeof(te);
>  -    ok(!pThread32First( hSnapshot, &te ), "shouldn't return a thread\n");
>  +    ret = pThread32First( hSnapshot, &te );
>  +    ok(ret || !ret, "You'll never see this\n");
>
>  renders the whole test useless.
>

That's the point; the test is useless.  If a test fails on one
platform but succeeds in another, then we're testing a behavior that
can't be relied on, or the test is not specific enough.  We leave it
around for documentation of that fact.

> It turns out that win9x in this case leaves
> te.dwSize and XP-and-up set te.dwSize to 0. Shouldn't we make use of that
> fact?
>

You could, but it doesn't change the fact that the behavior is not
reliable across different platforms.  If we knew an app that makes
this exact check and depends on the results, then sure we should add a
pickier test.  As it stands, it's just a bit too nit-picky.

>
>  On a sidenote (and this has been the case for a long time):
>
>  I've seen patches where
>
>  ok(function(a,b),"Failed");
>
>  is turned into
>
>  c = function(a,b);
>  if (c)
>  {
>   .....
>  }
>
>  but done without a skip or such. So if Wine has a regression for 'function'
> we won't notice.
>

Tell that to the platforms that fail too.  Thus, this is a behavior
that can't be relied on.  Wine strives to have compatibility with all
the platforms we test on.  We don't stick to one specific version, and
if we did, we could arbitrarily pick the version that fails this
function, then failing would be the right behavior.

>  We have loads of patches where we expect 3 or more different last errors.
> This will make sure the tests always succeed of course but makes it
> difficult to tell if we (Wine) are doing the correct/best thing.
>

You're missing the broader picture.  If a function returns three or
more different last errors, how can any app depend on that either?
What is the definition of the "correct/best thing"?

-- 
James Hawkins