On Wed, 5 Jan 2011, Dan Fandrich wrote:

> There's a bit of an ambiguity in the way the unit test framework handles
> errors in unit_setup() and unit_stop()--there's no way to signal that a
> fatal error has occurred. The torture tests, for example, ensure that a
> curl_easy_init() call in unit_setup() will fail, so the first test that uses
> that handle will cause a NULL pointer dereference.

Ah yes, this reminds me. I wonder if we should explicitly not do torture tests
on unit test cases. At least not in the way we do them for other tests. The
rationale for this would be that the actual programs that run in the unit test
cases aren't necessarily fine and proper programs with a full clean-up path,
but simply small snippets that exercise functions in the right order with the
right input. As the torture tests work now, we're going to have to write the
unit tests to never leak memory etc and there's really no particular benefit.

Possibly we should instead provide some kind of API/wrapper things for the
unit test suite so that it explicitly can run torture(-like) tests on selected
functions or portions of code.

> I suggest that unit_setup() return an error code, and if an error is
> indicated, then the test immediately aborts with a failure, and unit_stop()
> is never called. Something like this diff should work

Yes, I think we should do this no matter what the outcome of the above is.

> but if we wanted to get fancy, the error code number returned by
> unit_setup() (a CURLcode, probably) could be logged as well:

Right. And I have a suggestion on how to accomplish it:

We turn fail() into a real function that accepts printf-style arguments, and
we use that function instead of fprintf()+unitfail++ from the test macros.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html