Hi Jim,
> Not having to worry about cleaning up temporary files
> and not having to choose "parallel-safe" names for them
> leads to much cleaner tests.
> Not having to add signal handlers in every single one
> avoids duplication and would make them robust by default.
>
> IMHO, all new tests should use init.sh, but we haven't
> discussed whether this should be policy.
You do have a point about tests which create files. But there are many
more tests which don't fiddle with files. Let's take test-strncat.c as
an example.
An extra test-strncat.sh would mean
1) Extra files to distribute and to mention in the module description.
2) An extra indirection to consider when you want to debug a test failure
with gdb.
On the positive side: What would be the benefit?
- Last time you mentioned [1]: Interoperation with automake's parallel tests
mode. Nothing needs to be done for this; test-strncat.c works perfectly
fine with parallel-tests already now.
There is a nit that skipped tests, by gnulib conventions, print a reason
why the test is skipped, whereas parallel-tests hides this output. But IMO
this needs to be fixed on Automake's side.
parallel-tests offers the possibility to have verbose output be emitted
by the tests. This can be done through printf(), simply, optionally wrapped
in some macros defined in tests/macros.h.
- You mention signal handlers. But what's the difference? init.sh ensures
an exit code of 128+sig when signal sig has been caught. But that's
already the default for C programs.
- There is also MALLOC_PERTURB_. This can be set in TESTS_ENVIRONMENT
globally, or in a utility function called from main().
In summary, a shell wrapper for such tests is overkill. All extra functionality
can be done and is better done in C, possibly through function call test_init();
at the beginning of main(). I suggest to put these into tests/macros.h and
tests/init.c, if we find such functionality is needed.
Bruno
[1] http://lists.gnu.org/archive/html/bug-gnulib/2010-04/msg00094.html
