Writing tests

[Walt Ogburn]

Hi folks,

I have a question about dependencies when writing tests.  Some tests use
LoadLibraryA and GetProcessAddress to get access to Windows / Wine APIs,
and other tests just include the appropriate header files and link to the
DLLs.  One example of the first type is dlls/oleaut32/olefont.c:

================ <snip> ==============================================
static HMODULE hOleaut32;

static HRESULT (WINAPI
*pOleCreateFontIndirect)(LPFONTDESC,REFIID,LPVOID*);

START_TEST(olefont)
{
        LPVOID pvObj = NULL;
        HRESULT hres;
        IFont*  font = NULL;

hOleaut32 = LoadLibraryA("oleaut32.dll");
        pOleCreateFontIndirect = (void*)GetProcAddress(hOleaut32, "OleCreateFontIndirect");
        if (!pOleCreateFontIndirect)
            return;
=====================================================================

What is the reason for this difference?  Which example should new tests
follow?  My guess is that LoadLibraryA and GetProcAddress are used if the
headers, DLLs, and APIs might not be present on some Windows machines, so
that the tests don't fail.  If that's correct, is there a list somewhere
of which ones are safe and which ones should be handled like in the
olefont test?

Thanks,
Walter

[Francois Gouget]

On Wed, 27 Oct 2004, Walt Ogburn wrote:
[...]
> What is the reason for this difference?  Which example should new tests
> follow?  My guess is that LoadLibraryA and GetProcAddress are used if the
> headers, DLLs, and APIs might not be present on some Windows machines, so
> that the tests don't fail.

If the API is not going to be available on all Windows systems, then use 
LoadLibrary()+GetProcAddress() so we can at least run the other parts of 
the test on these platforms. In extreme cases you may have to tweak the 
test so it does not link at all with the dll it's supposed to test if 
that dll may be missing on some Windows versions (e.g. Windows 95 or 
98).

Otherwise just use the standard header+link method. If in doubt, go with 
with the header+link method and someone will fix the test if it does not 
compile/run on Windows anymore.
> If that's correct, is there a list somewhere
> of which ones are safe and which ones should be handled like in the
> olefont test?

The MSDN may tell you that the API is Windows 200+ or some such. But 
that's not very reliable: it's quite possible the API is there and just 
returns ERROR_NOT_IMPLEMENTED or some such.