[msi/tests] Install tests on win9x and NT4

[Paul Vriens]

Hi,

Currently the install test fail/crash on at least win95 and NT4. The main reason 
I found was that pMsiQueryComponentStateA and pMsiSourceListGetInfoA are not 
guarded.

Does it makes sense to guard every instance of these calls and just continue:

if (pMsiSourceListGetInfoA)
{
    call
    test outcome
}

or should we skip the whole subtest when the function is not available.

Guarding each single item requires 28 of these if-statements or is there an 
other alternative? (like creating a function/macro to deal with this)

Just guarding the functions makes the tests not crash but they still fail (that 
is another issue of course).

[James Hawkins]

On Jan 23, 2008 5:20 AM, Paul Vriens  wrote:
> Hi,
>
> Currently the install test fail/crash on at least win95 and NT4. The main reason
> I found was that pMsiQueryComponentStateA and pMsiSourceListGetInfoA are not
> guarded.
>
> Does it makes sense to guard every instance of these calls and just continue:
>
> if (pMsiSourceListGetInfoA)
> {
>     call
>     test outcome
> }
>
> or should we skip the whole subtest when the function is not available.
>
> Guarding each single item requires 28 of these if-statements or is there an
> other alternative? (like creating a function/macro to deal with this)

Logically, guarding each call is the exact same as not running the
tests at all, so just check at the beginning of
test_MsiSourceListGetInfo and skip the tests if the pointer is NULL.

[Paul Vriens]

On Jan 23, 2008 5:53 PM, James Hawkins  wrote:
> On Jan 23, 2008 5:20 AM, Paul Vriens  wrote:
> > Hi,
> >
> > Currently the install test fail/crash on at least win95 and NT4. The main reason
> > I found was that pMsiQueryComponentStateA and pMsiSourceListGetInfoA are not
> > guarded.
> >
> > Does it makes sense to guard every instance of these calls and just continue:
> >
> > if (pMsiSourceListGetInfoA)
> > {
> >     call
> >     test outcome
> > }
> >
> > or should we skip the whole subtest when the function is not available.
> >
> > Guarding each single item requires 28 of these if-statements or is there an
> > other alternative? (like creating a function/macro to deal with this)
>
> Logically, guarding each call is the exact same as not running the
> tests at all, so just check at the beginning of
> test_MsiSourceListGetInfo and skip the tests if the pointer is NULL.

Well, I asked because there are more single tests in those subtests.
As the 2 are mainly gathering information
I thought to at least run the other ones.

As we are 'only' talking about win95 and NT4 I think I opt for your
statement to just guard at the beginning. If we ever find an app
that doesn't install on win95/NT4 and relies on the now not running
tests we can always change that.

Cheers,

Paul.

[Reece Dunn]

On 23/01/2008, Paul Vriens  wrote:
> Hi,
>
> Currently the install test fail/crash on at least win95 and NT4. The main reason
> I found was that pMsiQueryComponentStateA and pMsiSourceListGetInfoA are not
> guarded.
>
> Does it makes sense to guard every instance of these calls and just continue:
>
> if (pMsiSourceListGetInfoA)
> {
>     call
>     test outcome
> }
>
> or should we skip the whole subtest when the function is not available.

It depends on what the test is doing. If the test needs the result of
that function to run the remainder of the sub-test, it shoud skip the
remainder of the sub-test (preferably with some information on why the
test is skipped). If the test is only using that function to get some
extended information, then each instance needs to be guarded.

In general, i suspect that most of these will result in the sub-test
being skipped (especially if that function is what is being tested).

As for any helper macros, in the case where the sub-test is skipped, a
macro could be created to simplify this. Apart from that, I don't know
of anything to simplify it. Besides, having the conditional for
non-skipping sub-tests makes it explicit what the codepath is.

- Reece