On 1 Jan 2002, Alexandre Julliard wrote:
Jeremy White jwhite@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@free.fr http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean