git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "SZEDER Gábor" <szeder@ira.uka.de>
To: Sverre Rabbelier <srabbelier@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH] test-lib: write test results to test-results/<basename>-<pid>
Date: Sat, 14 Mar 2009 14:59:04 +0100	[thread overview]
Message-ID: <20090314135904.GL6808@neumann> (raw)
In-Reply-To: <fabb9a1e0903140616q3770f89axff84755abb1f47c7@mail.gmail.com>

Hi,

On Sat, Mar 14, 2009 at 02:16:57PM +0100, Sverre Rabbelier wrote:
> On Sat, Mar 14, 2009 at 13:28, SZEDER Gábor <szeder@ira.uka.de> wrote:
> > With my proposed change there would be no need to clean 'test-results'
> > before running the tests, because test-lib.sh would take care of that
> > (not by removing and recreating 'test-results/', but by overwriting
> > (IOW: removing and recreating, but in one step) individual test result
> > files).
> 
> Wouldn't that result in possible stale files being counted in the
> result (e.g., if those tests were not run this time, but they were run
> previously)?

It depends.

If you run only a few tests, then you do it with a command like 'make
t1234-foo.sh t5678-bar.sh'.

Currently this doesn't run the 'pre-clean' target, therefore if you
run different tests (e.g. 'make t1234-foo.sh ; make t5678-bar.sh'),
then a 'make aggregate-results' will include the result of both of
those tests.  The same happens with my proposal, too, because the test
of the last run will not overwrite the results of the test in the
first run.

Now suppose that you want to run the same set of tests twice (or more;
e.g. 'make t1234-foo.sh ; make t1234-foo.sh ; make
aggregate-results').  Since currently the pid of the test is included
in the test result file name, there will be two files (t1234-<pid1>
and t1234-<pid2>) created under 'test-results/', and _both_ will be
counted by 'aggregate-results'.  In this case my proposal is better,
because the last round will overwrite the result of the previous runs,
therefore no stale files will be counted.


Best,
Gábor

  reply	other threads:[~2009-03-14 14:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1236961524u.git.johannes.schindelin@gmx.de>
2009-03-13 16:26 ` [PATCH] test-lib: write test results to test-results/<basename>-<pid> Johannes Schindelin
2009-03-13 16:36   ` Johannes Schindelin
2009-03-13 17:20     ` SZEDER Gábor
2009-03-13 17:44       ` SZEDER Gábor
2009-03-14 11:53       ` Johannes Schindelin
2009-03-14 12:16         ` SZEDER Gábor
2009-03-14 12:22           ` Johannes Schindelin
2009-03-14 12:28             ` SZEDER Gábor
2009-03-14 13:16               ` Sverre Rabbelier
2009-03-14 13:59                 ` SZEDER Gábor [this message]
2009-03-16 10:18                 ` Johannes Schindelin
2009-03-16 10:41                   ` SZEDER Gábor
2009-03-13 17:20     ` Junio C Hamano
2009-03-13 17:22       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090314135904.GL6808@neumann \
    --to=szeder@ira.uka.de \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=srabbelier@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).