bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

init.sh and C tests


From: Bruno Haible
Subject: init.sh and C tests
Date: Sun, 23 May 2010 12:14:04 +0200
User-agent: KMail/1.9.9

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]