All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, peter.maydell@linaro.org, eblake@redhat.com
Subject: Re: [Qemu-devel] [PATCH 2/2] test: replace gtester with a TAP driver
Date: Fri, 30 Nov 2018 17:19:28 +0100	[thread overview]
Message-ID: <100f07e5-8067-3d68-afab-9896032927c9@redhat.com> (raw)
In-Reply-To: <20181130155003.GG9162@redhat.com>

On 30/11/18 16:50, Daniel P. Berrangé wrote:
> IIUC, this output is only seen when you with 'make check' passing V=1,
> so most people won't see it.

V=1 should be enabled by default on Patchew, so it will be visible in
the CI logs.  But anyway that's minor, there are more reasons why a
custom beautifier is better than prove.

First, at the very least, failures should be included in the output even
if V=1 is not provided.  Therefore, for failing tests we'd have:

  $ scripts/tap-driver.pl < f.tap
  FAIL 2 bbb
  XPASS 3 ccc # TODO
  FAIL 6 fff # SKIP cannot find frobnicator

And the output of prove in that case would be inferior for developers,
unless you use "V=1":

  $ prove -e cat f.tap
  f.tap .. Failed 2/6 subtests
	(less 2 skipped subtests: 2 okay)
	(1 TODO test unexpectedly succeeded)

  Test Summary Report
  -------------------
  f.tap (Wstat: 0 Tests: 6 Failed: 2)
    Failed tests:  2, 6
    TODO passed:   3
  Files=1, Tests=6,  0 wallclock secs ( 0.02 usr +  0.00 sys =  0.02 CPU)
  Result: FAIL

where you don't really know what tests 2 and 6 are without looking at
the TAP output.  The part before the summary provides a nice progress
report, as you point out, but it adds a bunch of noise with respect to
skipped subtests (skipped tests will be more common once patch 1 is
merged; qgraph also adds some) that I personally dislike.

You can hide it with -Q, but then you cannot invoke anymore more than
one test with a single invocation of prove, and the Makefile output
becomes much bigger:

   TEST    check-foo

vs.

   TEST    check-foo
  All tests successful.
  Files=1, Tests=3,  0 wallclock secs ( 0.01 usr +  0.00 sys =  0.01 CPU)
  Result: PASS

There are two other smaller "philosophical" differences.  First, prove
treats XPASS as passes, while tap-driver.pl treats them as failures.
Second, skipped tests really stand out in the "prove -v" output, with
white-on-blue text.

I'd rather avoid getting into the business of beautifying the output of
prove.

Paolo

  reply	other threads:[~2018-11-30 16:19 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-29 17:45 [Qemu-devel] [PATCH for-4.0 0/2] test: replace gtester with a TAP driver Paolo Bonzini
2018-11-29 17:45 ` [Qemu-devel] [PATCH 1/2] test: execute g_test_run when tests are skipped Paolo Bonzini
2018-11-29 20:48   ` Eric Blake
2018-11-30  7:10   ` Thomas Huth
2018-11-29 17:45 ` [Qemu-devel] [PATCH 2/2] test: replace gtester with a TAP driver Paolo Bonzini
2018-11-29 21:06   ` Eric Blake
2018-11-29 22:04     ` Paolo Bonzini
2018-11-30 15:50   ` Daniel P. Berrangé
2018-11-30 16:19     ` Paolo Bonzini [this message]
2018-11-29 20:43 ` [Qemu-devel] [PATCH for-4.0 0/2] " Eric Blake
2018-11-30  7:21   ` Thomas Huth
2018-11-30  9:58     ` Paolo Bonzini
2018-11-30 14:47       ` Cleber Rosa
2018-11-30 15:05         ` Thomas Huth
2018-11-30  9:54   ` Daniel P. Berrangé
2018-11-30  9:56     ` Paolo Bonzini
2018-11-30 10:21       ` Daniel P. Berrangé
2018-12-06 21:50 [Qemu-devel] [PATCH for-4.0 v2 " Paolo Bonzini
2018-12-06 21:50 ` [Qemu-devel] [PATCH 2/2] " Paolo Bonzini
2018-12-07  6:15   ` Thomas Huth
2019-02-08 12:48   ` Kevin Wolf
2019-02-08 13:46     ` Paolo Bonzini
2019-02-08 16:00       ` Kevin Wolf
2019-02-08 17:16         ` Paolo Bonzini
2019-02-11 14:32           ` Kevin Wolf
2019-02-11 14:54             ` Paolo Bonzini
2019-07-01 14:42   ` Philippe Mathieu-Daudé
2019-07-03 11:29     ` Paolo Bonzini

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=100f07e5-8067-3d68-afab-9896032927c9@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=berrange@redhat.com \
    --cc=eblake@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.