On Friday 28 December 2001 05:00, Andreas Mohr wrote:
Yes, IMHO we really need a C based test.
I'd go along with this. It seems that a variety of tests, written and contributed by a variety of people, and thus written in a variety of mutually inconsistent and collectively odd ways, is inevitable. Rather than people wasting their valuable time on rejigging any existing "modular extensible test framework" or writing anything new, the simplist way forward would surely be to document some simple input/output behaviours test programs should use.
Eg. as long as it is described what should and should not be sent by a test program to stdout+stderr, and what input (if any) should be supported on the command line and/or stdin, then you have achieved the only consistency that matters. A simple shell script could then, for example, control the level of debugging in any/all such tests by simply piping output(s) through egrep or whatever - stdout itself could be piped to /dev/null if necessary leaving only stderr, etc.
Let's face it - anyone adding new functionality to wine or working on anything non-trivial will be cooking up their own "foo.c" test programs on the fly when developing - the less work it takes for that developer to convert their foo.c into a test-foo32-api.c for use by test scripts, the better off everyone will be.
Let's also not forget, if that "standardised form" for input/output of the testing is as logical and uncomplicated as possible, more and more well-meaning code grunts will be capable of making useful contributions - be it clunky GUI wrappers for the testing suites (think what "make xconfig" did for linux kernel rebuilding), or by even taking the various foo.c test fragments from the wine developers and coaxing them into the standardised form on their behalfs.
If a "testing framework" is anything more complicated - the only people working on the test suites will be whoever defines/understands the "test framework specification" and the hard-core wine developers themselves. In other words, we won't get far.
Cheers, Geoff