widl: Add a framework for automated testing of IDL files that should succeed or fail to be parsed.

Dan Hipschman dsh at linux.ucla.edu
Mon Apr 28 15:53:43 CDT 2008


On Mon, Apr 28, 2008 at 08:37:26PM +0100, Robert Shearman wrote:
> 
> This should aid in testing more-obscure parts of the parser that aren't 
> necessarily valid when using RPC (and hence don't make sense being put 
> in dlls/rpcrt4/tests/server.idl).

Obviously this is a good idea.  I tried doing something similar a while
ago, but it didn't get accepted on the first try and I never asked why,
so I'll ask why now.  See here:

http://winehq.org/pipermail/wine-patches/2006-September/030438.html

It has some benefits over the approach you're proposing so it's worth
bringing up.  One is that it can run the tests against MIDL, so we know
the tests themselves are correct (ok, MIDL has been known to do things
differently than the spec, but we may want to copy MIDL's behaviour
anyway, and in any case it's easier to automatically validate the tests
on MIDL than to do so by hand or by inspection).

Another is versatility in what it can test.  Since the tests are shell
scripts, not only can it test the success/failure of a parse, but it can
check that all the correct files were created, and it can perform
further tests on the output (e.g., if we have an import in the IDL file,
we can grep the output to make sure a #include was generated for the
import).

It already supports "todo"s, and the test scripts look similar to the
usual Wine tests written in C.

On the other hand your method has some advantages over mine.  You
already provide a "make test" framework, and including the expected
result of the compilation in the IDL file is cleaner.

Alexandre may very well disagree with what I see as valid points (like
testing on MIDL), but these are my suggestions anyway.  Hope they're
useful.



More information about the wine-devel mailing list