Re: Do not terminate default test runs on test failure

["Carlos O'Donell" <carlos at redhat dot com>]

On 03/07/2014 12:42 PM, Joseph S. Myers wrote:
> This patch is an updated version of
> <https://sourceware.org/ml/libc-alpha/2014-01/msg00198.html> now
> proposed for inclusion in glibc.
> 
> Normal practice for software testsuites is that rather than
> terminating immediately when a test fails, they continue running and
> report at the end on how many tests passed or failed.
> 
> The principle behind the glibc testsuite stopping on failure was
> probably that the expected state is no failures and so any failure
> indicates a problem such as miscompilation.  In practice, while this
> is fairly close to true for native testing on x86_64 and x86 (kernel
> bugs and race conditions can still cause intermittent failures), it's
> less likely to be the case on other platforms, and so people testing
> glibc run the testsuite with "make -k" and then examine the logs to
> determine whether the failures are what they expect to fail on that
> platform, possibly with some automation for the comparison.
> 
> This patch switches the glibc testsuite to the normal convention of
> not stopping on failure - unless you use stop-on-test-failure=y, in
> which case it behaves essentially as it did before (and does not
> generate overall test summaries on failure).  Instead, the summary
> tests.sum may contain tests that FAILed.  At the end of the test run,
> any FAIL or ERROR lines from tests.sum are printed, and then it exits
> with error status if there were any ERROR lines (meaning a directory
> had no test results).  In addition, build failures will also cause the
> test run to stop - this has the justification that those *do* indicate
> serious problems that should be promptly fixed and aren't generally
> hard to fix (but apart from that, avoiding the build stopping on those
> failures seems harder).
> 
> Note that unlike the previous patches in this series, this *does*
> require people with automation around testing glibc to change their
> processes - either to start using tests.sum / xtests.sum to track
> failures and compare them with expectations (with or without also
> using "make -k" and examining "make" logs to identify build failures),
> or else to use stop-on-test-failure=y and ignore the new tests.sum /
> xtests.sum mechanism.
> 
> Tested x86_64.
> 
> Compared to the previous version, this includes changes to the manual
> text as suggested by Brooks in
> <https://sourceware.org/ml/libc-alpha/2014-02/msg00301.html>.
> 
> This concludes the present series of patches to generate PASS / FAIL
> test results and fix associated testsuite issues.  Once it's in, I
> intend to put the remaining TODO list items from the discussions of
> these patches on the wiki.  I may return later to further testsuite
> infrastructure improvements (such as supporting installed testing),
> but also encourage other people interested in testsuite issues to work
> on issues of interest to them (whether or not also listed on the wiki
> todo list or in Bugzilla).
> 
> 2014-03-07  Joseph Myers  <joseph@codesourcery.com>
> 
> 	* scripts/evaluate-test.sh: Handle fourth argument to determine
> 	whether test run should stop on failure.
> 	* Makeconfig (stop-on-test-failure): New variable.
> 	(evaluate-test): Pass fourth argument to evaluate-test.sh based on
> 	$(stop-on-test-failure).
> 	* Makefile (tests): Give a summary of results from testing and
> 	exit with failure status if they include an ERROR.
> 	(xtests): Likewise.
> 	* manual/install.texi (Configuring and compiling): Mention
> 	stop-on-test-failure=y.
> 	* INSTALL: Regenerated.

OK, modulo parenthetical nit below.

I would prefer you split this into two patches, a minimal patch
to support running without `-k' and another for all the other
changes, but I'm not opposed to one patch for this change.
The first patch would change nothing, but add the variable,
and the second patch changes the default and includes the summary
changes.

> diff --git a/INSTALL b/INSTALL
> index bfa692d..bcb53b8 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -154,7 +154,7 @@ will be used, and CFLAGS sets optimization options for the compiler.
>  
>       If you only specify `--host', `configure' will prepare for a
>       native compile but use what you specify instead of guessing what
> -     your system is. This is most useful to change the CPU submodel.
> +     your system is.  This is most useful to change the CPU submodel.

OK. Split into another patch?

>       For example, if `configure' guesses your machine as
>       `i686-pc-linux-gnu' but you want to compile a library for 586es,
>       give `--host=i586-pc-linux-gnu' or just `--host=i586-linux' and add
> @@ -192,11 +192,16 @@ an appropriate numeric parameter to `make'.  You need a recent GNU
>  
>     To build and run test programs which exercise some of the library
>  facilities, type `make check'.  If it does not complete successfully,
> -do not use the built library, and report a bug after verifying that the
> -problem is not already known.  *Note Reporting Bugs::, for instructions
> -on reporting bugs.  Note that some of the tests assume they are not
> -being run by `root'.  We recommend you compile and test the GNU C
> -Library as an unprivileged user.
> +or if it reports any unexpected failures or errors in its final summary
> +of results, do not use the built library, and report a bug after
> +verifying that the problem is not already known.  (You can specify
> +`stop-on-test-failure=y' when running `make check' to make the test run
> +stop and exit with an error status immediately when a failure occurs,
> +rather than completing the test run and reporting all problems found.)

Remove parenthetical. This is a fine statement to make at this point in
the document.

> +*Note Reporting Bugs::, for instructions on reporting bugs.  Note that
> +some of the tests assume they are not being run by `root'.  We
> +recommend you compile and test the GNU C Library as an unprivileged
> +user.

OK.

>  
>     Before reporting bugs make sure there is no problem with your system.
>  The tests (and later installation) use some pre-existing files of the
> diff --git a/Makeconfig b/Makeconfig
> index 9078b29..0a2e12b 100644
> --- a/Makeconfig
> +++ b/Makeconfig
> @@ -601,6 +601,12 @@ run-built-tests = yes
>  endif
>  endif
>  
> +# Whether to stop immediately when a test fails.  Nonempty means to

OK.

> +# stop, empty means not to stop.
> +ifndef stop-on-test-failure
> +stop-on-test-failure =
> +endif
> +
>  # How to run a program we just linked with our library.
>  # The program binary is assumed to be $(word 2,$^).
>  built-program-file = $(dir $(word 2,$^))$(notdir $(word 2,$^))
> @@ -1091,6 +1097,7 @@ test-xfail-name = $(strip $(patsubst %.out, %, $(patsubst $(objpfx)%, %, $@)))
>  # XPASS or XFAIL rather than PASS or FAIL.
>  evaluate-test = $(..)scripts/evaluate-test.sh $(test-name) $$? \
>  		  $(if $(test-xfail-$(test-xfail-name)),true,false) \
> +		  $(if $(stop-on-test-failure),true,false) \

OK.

>  		  > $(common-objpfx)$(test-name).test-result
>  
>  endif # Makeconfig not yet included
> diff --git a/Makefile b/Makefile
> index 8214dda..bdece42 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -324,10 +324,20 @@ tests: $(tests-special)
>  	$(..)scripts/merge-test-results.sh -t $(objpfx) subdir-tests.sum \
>  	  $(sort $(subdirs) .) \
>  	  > $(objpfx)tests.sum
> +	@grep '^ERROR:' $(objpfx)tests.sum || true
> +	@grep '^FAIL:' $(objpfx)tests.sum || true
> +	@echo "Summary of test results:"
> +	@sed 's/:.*//' < $(objpfx)tests.sum | sort | uniq -c
> +	@if grep -q '^ERROR:' $(objpfx)tests.sum; then exit 1; fi
>  xtests:
>  	$(..)scripts/merge-test-results.sh -t $(objpfx) subdir-xtests.sum \
>  	  $(sort $(subdirs)) \
>  	  > $(objpfx)xtests.sum
> +	@grep '^ERROR:' $(objpfx)xtests.sum || true
> +	@grep '^FAIL:' $(objpfx)xtests.sum || true
> +	@echo "Summary of test results for extra tests:"
> +	@sed 's/:.*//' < $(objpfx)xtests.sum | sort | uniq -c
> +	@if grep -q '^ERROR:' $(objpfx)xtests.sum; then exit 1; fi

OK. Split into another patch?

>  
>  # The realclean target is just like distclean for the parent, but we want
>  # the subdirs to know the difference in case they care.
> diff --git a/NEWS b/NEWS
> index 0c5b39a..381b8a5 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -12,6 +12,14 @@ Version 2.20
>    15347, 15804, 15894, 16447, 16532, 16545, 16574, 16600, 16609, 16610,
>    16611, 16613, 16623, 16632.
>  
> +* Running the testsuite no longer terminates as soon as a test fails.
> +  Instead, a file tests.sum (xtests.sum from "make xcheck") is generated,
> +  with PASS or FAIL lines for individual tests.  A summary of the results is
> +  printed, including a list of failing lists, and "make check" exits with
> +  error status only if test results for a subdirectory are completely
> +  missing, or if a test failed to compile.  "make check
> +  stop-on-test-failure=y" may be used to keep the old behavior.
> +

OK. Split into another patch?

>  * The am33 port, which had not worked for several years, has been removed
>    from ports.
>  
> diff --git a/manual/install.texi b/manual/install.texi
> index 8562bdc..fa44519 100644
> --- a/manual/install.texi
> +++ b/manual/install.texi
> @@ -224,9 +224,14 @@ GNU @code{make} version, though.
>  
>  To build and run test programs which exercise some of the library
>  facilities, type @code{make check}.  If it does not complete
> -successfully, do not use the built library, and report a bug after
> -verifying that the problem is not already known.  @xref{Reporting Bugs},
> -for instructions on reporting bugs.  Note that some of the tests assume
> +successfully, or if it reports any unexpected failures or errors in
> +its final summary of results, do not use the built library, and report
> +a bug after verifying that the problem is not already known.  (You can
> +specify @samp{stop-on-test-failure=y} when running @code{make check}
> +to make the test run stop and exit with an error status immediately
> +when a failure occurs, rather than completing the test run and
> +reporting all problems found.)  @xref{Reporting Bugs}, for
> +instructions on reporting bugs.  Note that some of the tests assume

OK.

>  they are not being run by @code{root}.  We recommend you compile and
>  test @theglibc{} as an unprivileged user.
>  
> diff --git a/scripts/evaluate-test.sh b/scripts/evaluate-test.sh
> index c8f5012..2a5c156 100755
> --- a/scripts/evaluate-test.sh
> +++ b/scripts/evaluate-test.sh
> @@ -17,12 +17,13 @@
>  # License along with the GNU C Library; if not, see
>  # <http://www.gnu.org/licenses/>.
>  
> -# usage: evaluate-test.sh test_name rc xfail
> +# usage: evaluate-test.sh test_name rc xfail stop_on_failure

OK.

>  
>  test_name=$1
>  rc=$2
>  orig_rc=$rc
>  xfail=$3
> +stop_on_failure=$4
>  
>  if [ $rc -eq 0 ]; then
>    result="PASS"
> @@ -37,4 +38,8 @@ fi
>  
>  echo "$result: $test_name"
>  echo "original exit status $orig_rc"
> -exit $rc
> +if $stop_on_failure; then
> +  exit $rc
> +else
> +  exit 0
> +fi
> 

Cheers,
Carlos.