Andriy Palamarchuk apa3a@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.