C testing framework. ASCII/Unicode portable version

[Dimitrie O. Paun]

On Tue, 22 Jan 2002, Andriy Palamarchuk wrote:

> --- "Dimitrie O. Paun" <dimi at 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.