C testing framework. ASCII/Unicode portable version

[Alexandre Julliard]

Andriy Palamarchuk <apa3a at yahoo.com> writes:

> Alexandre, one time you were saying than W and A
> functions can't be tested by the same code because
> they are completely different. 
> Now you are saying that we don't need to test W
> function because they are no more than conversion to
> ASCII, calling A function, converting results back to
> Unicode and it is sufficient to test A function and
> check the conversions.

No, I'm not saying this is what we should do, I'm saying this is what
you are doing with your TCHAR stuff. If your test does:

foo(_T("abc"))

it essentially does:

fooA("abc")
fooW(L"abc")

but in most cases since fooA converts the string and calls fooW
already you are not really testing anything more than by simply
calling fooA. This doesn't mean that you shouldn't test fooW at all,
but the interesting thing to do is to test fooW with Unicode input. So
you should do something like:

fooA("abc")
fooW(L"some unicode chars here")

Now with your solution:

foo(_T("abc"))
#ifdef UNICODE
  fooW(L"some unicode chars here")
#endif

the test is more complex to write, it takes twice as long to compile
and run, and it doesn't test more than my version.

And this doesn't even get into testing behavior with mixed A/W
calls. To take a random example, to test CreateEvent you'll want to
use OpenEvent to verify that the event was created. With TCHAR all you
will ever test is that OpenEventA finds an event created by
CreateEventA, and OpenEventW finds one created by CreateEventW. You
will never test interesting combinations like CreateEventA/OpenEventW
because it's a big pain to write.

> Using TCHAR insures that A and W functions have the
> same behaviour.
> Why you are against using the same code for this and
> using encoding-specific code to check the differences?

Because it makes writing a small subset of tests slightly easier at
the cost of making the really interesting tests much more painful to
write. Not a good trade-off.

-- 
Alexandre Julliard
julliard at winehq.com