We *really* need a development model change !

[Francois Gouget]

On 1 Jan 2002, Alexandre Julliard wrote:

> Jeremy White <jwhite at codeweavers.com> writes:
>
> > I've started playing with this, Alexandre, and I had a thought/question:
> > why not put the tests under 'wine/tests'?  I recognize the benefit
> > of having a test immediately associated with the implementation.
> > But, I would argue
> >           a)  that not all tests are going to be specific to one dll
>
> It seems to me that a given test should always be specific not only to
> a dll, but to a single or a few functions of this dll. When do you
> think this would not be the case?

   I can think of one case that I burn to put into the Wine testing
framework: the command line/argv/argv handling. I think it
would make sense to test simultaneously:
 * kernel32.CreateProcess
   It is clearly involved when the parent proces is a Wine process
 * kernel32.GetCommandLineA/W
   Clearly related
 * main and WinMain
   Not from a specific dll
 * msvcrt.__getmainargs
   One of the ways to retrieve the parameters
 * msvcrt.__argc, msvcrt.__argv, msvcrt.__wargv
   Other functions returning the process's parameters
 * shell32.CommandLineToArgvW
   Not involved int the process creation but performs exactly the same
   command line to argument array conversion that is involved in there.
   So I think it makes sense to test it in the same program.


   But I believe that even that case can fit reasonably well in the test
architecture. For instance we could to these tests in msvcrt/test since
msvcrt depends on kernel32. Then it's just a matter of
CommandLineToArgvW that we may want to separate.


[...]
> >           b)  by placing all the tests together, you make exporting
> >                 a 'test' package to Windows simpler.
> >           c)  You centralize the info and allow for good doco
> >           d)  We can create and sustain a whole Windows make
> >                 file hierarchy, which would be useful to a test
> >                 writer in Windows.

   I think the real rational for putting tests in a separate directory
would be to make them completely separate from Wine. After all a Win32
conformance test suite could also benefit other projects like Odin,
ReactOS?, and any other Win32 reimplementation. Thus there may be an
argument that it could be beneficial to have a test suite that everyone
could contribute to. It could even be under a different license, like
GPL to ensure that all projects contribute to it fairly (and who wants a
proprietary Win32 conformance suite anyway). Such a strategy would even
mke more sense if there was already such a test suite out there.

   But I'm not aware of any such test suite so I say we should start
with an integrated test suite which seems more practical at the moment
and we'll see when the time comes if we need to separate it from Wine.


--
Francois Gouget         fgouget at free.fr        http://fgouget.free.fr/
The nice thing about meditation is that it makes doing nothing quite respectable
                                  -- Paul Dean