On Tue, 22 Jan 2002, Andriy Palamarchuk wrote:
--- "Dimitrie O. Paun" dimi@cs.toronto.edu wrote:
I have a number of observations: -- we should rename wt_helper.h to something like wine/tests.h
I'm open for suggestions. I used this name to avoid name clashes with Perl winetest framework. BTW, wt = Wine Test.
Well, yeah, I figured that much, but is ugly like hell.
I'd prefer more recognizable name than "test.h".
It's not test.h, it's wine/tests.h which is both clean, recognizable, and pretty. In code, you have:
#include "wine/tests.h"
-- maybe we should not use main as the main funtion, but rather something like 'test'. This way we can provide the main and have another level of indirection which can be put to good use. (like we should not need the explicit end_tests()) -- another thing we can do is to have the tests in
functions named testXXX. This way we can use nm to generate the main function, and so we can
put a bunch of tests in the same executable.
Whether we'll use these ideas depends on architecture of the whole testing process.
Duh! :) But I thought that's what we're working on...:)
-- wt_helper.h should include tchar.h, and redefine _T to call a function to transform the string to Unicode if need be. This way we get rid of the compiler requirement.
Using function instead of macro won't work in all the cases, e.g. in this one:
_TCHAR buf[100] = _T("foo")
So, don't do that. Francois showed a number of good ways of doing it. In any case, I think we should discourage the use of explicit strings in the tests, for reasons outlined by Alexandre. I think we should use a teststr() call instead of most hardcoded strings.
-- I still think my teststr() idea is worth doing. Do you want an implementation?
I like the idea, but do not need such Unicode strings generator for my test :-) Can you implement it with a small real test which shows advantages of teststr()?
Fine, I'll try to do that, it's just that I'm _very_ busy at the moment. I guess this means more late nights... :)
-- Why do you do: _T(__FILE__) Files are ASCII, no need to _T them.
__FILE__is a macro which is expanded to file name. I use _T with it for simplicity - to have the same ASCII/Unicode mode processing for everything. Otherwise I'd have to explicitely call ASCII functions for file names processing, probably do A->W conversion.
But we don't need it. I know what __FILE__ does, it returns an ASCII string, so we should just work with it as such.
-- Dimi.