From: Bryce McKinlay <mckinlay@redhat.com>
To: David Gilbert <david.gilbert@object-refinery.com>
Cc: Anthony Balkissoon <abalkiss@redhat.com>,
classpath@gnu.org, mauve-discuss@sources.redhat.com
Subject: Re: Mauve wishlist
Date: Tue, 21 Mar 2006 23:08:00 -0000 [thread overview]
Message-ID: <4420874C.2090800@redhat.com> (raw)
In-Reply-To: <4420336F.4070602@object-refinery.com>
David Gilbert wrote:
> 1) constant number of tests, regardless of exceptions being thrown or
> Mauve does have a design flaw where it can be tricky to automatically
> assign a unique identifier to each check(), and this makes it hard to
> compare two Mauve runs (say a test of the latest Classpath CVS vs the
> last release, or the Classpath vs JDK 1.5 - both of which would be
> interesting).
Right. We all understand the problem - its just the solution is what we
need to agree on :)
> I think the absolute number is meaningless however you count the
> tests, so I don't see this as an advantage.
Yes, numbers alone are meaningless, but with the current design, all the
results are meaningless without a lot of context. The real issue is
having a simple way to uniquely identify each test case for the purpose
of identifying regressions. This becomes fundamentally much easier when
1 test() method corresponds to one test case.
It is not reasonable to expect test case developers ensure that all
tests "run linearly". Exceptions can potentially be thrown at any time,
so to ensure linearity, every check() call would need wrapped with a
try/catch.
> You'll lose the ability to distinguish between an existing failure
> where (say) 1 out of 72 checks fail, and after some clever patch 43
> out of 72 checks fail, but the new system reports both as 1 test failure.
This is a valid concern. However, we will still track exactly which
check() calls fail so that in the event of a test failure, a full
diagnostic can be provided. In addition, we can still count the total
number of check() calls executed, for statistical purposes.
If the reduced test-case granularity does prove to be problematic in
some cases - say some test() where a small number of checks fail for
cases that are "hard to fix" problems and thus should be "xfailed" (to
use gcc/dejagnu lingo), then that test case should probably be split.
Alternatively, to avoid splitting things across multiple test classes,
we could add JUnit-style support for multiple test() methods in a single
test class.
Bryce
next prev parent reply other threads:[~2006-03-21 23:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-17 16:27 Thomas Fitzsimmons
2006-03-17 21:06 ` David Daney
2006-03-18 8:15 ` Michael Koch
2006-03-17 22:34 ` Audrius Meskauskas
2006-03-20 10:53 ` Arnaud Vandyck
2006-03-20 16:51 ` Anthony Balkissoon
2006-03-21 16:58 ` David Gilbert
2006-03-21 22:24 ` Tom Tromey
2006-03-21 23:08 ` Bryce McKinlay [this message]
2006-03-22 11:12 ` David Gilbert
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=4420874C.2090800@redhat.com \
--to=mckinlay@redhat.com \
--cc=abalkiss@redhat.com \
--cc=classpath@gnu.org \
--cc=david.gilbert@object-refinery.com \
--cc=mauve-discuss@sources.redhat.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 read-only IMAP folder(s) and NNTP newsgroup(s).