Exiting a tests on the first failure

[Paul Vriens]

Hi,

I'm currently looking into the shreg test of shlwapi. In the error-logs
on test.winehq.org I see a lot of errors.

If the first CreateKey fails, there is no need to continue with the
testing (because the rest of the tests will fail as well). What's the
best way to stop there?, something like this?:

START_TEST(shreg)
{
        HKEY hkey = create_test_entries();
+        if (!hkey) return;

Cheers,

Paul Vriens.

[Ferenc Wagner]

Paul Vriens  writes:
> If the first CreateKey fails, there is no need to continue with the
> testing (because the rest of the tests will fail as well). What's the
> best way to stop there?, something like this?:
>
> START_TEST(shreg)
> {
>         HKEY hkey = create_test_entries();
> -
>    if (!hkey) return;

Looks fine for me, given that in wine/test.h we have
#define START_TEST(name) void func_##name(void)

[Alexandre Julliard]

Paul Vriens  writes:
> If the first CreateKey fails, there is no need to continue with the
> testing (because the rest of the tests will fail as well). What's the
> best way to stop there?, something like this?:
>
> START_TEST(shreg)
> {
>         HKEY hkey = create_test_entries();
> -
>    if (!hkey) return;

No, the best way is to fix the test to use a key that works on all
platforms. The test case is useless otherwise.

[Paul Vriens]

On Mon, 2005-01-17 at 13:24, Alexandre Julliard wrote:
> Paul Vriens  writes:
> > If the first CreateKey fails, there is no need to continue with the
> > testing (because the rest of the tests will fail as well). What's the
> > best way to stop there?, something like this?:
> >
> > START_TEST(shreg)
> > {
> >         HKEY hkey = create_test_entries();
> > -
> >    if (!hkey) return;
>
> No, the best way is to fix the test to use a key that works on all
> platforms. The test case is useless otherwise.

Hi Alexandre,

is it OK that have the above in a patch anyway, along with some extra
debugging output? I will try and find a key we can use, but one problem
could be that the failures are related to security (that's why I want to
have the extra output as well).
If it is security it will probably be harder to find a key which we can
use.

Cheers,

Paul.

[Alexandre Julliard]

Paul Vriens  writes:
> is it OK that have the above in a patch anyway, along with some extra
> debugging output? I will try and find a key we can use, but one problem
> could be that the failures are related to security (that's why I want to
> have the extra output as well).

We want more than extra debugging output, we really want the test to
fail so that someone looks into it. We can't just pretend that
everything is fine if we actually didn't run any test at all.