From: Andrew Cagney <cagney@redhat.com>
To: Mark Wielaard <mark@klomp.org>
Cc: frysk@sourceware.org
Subject: Re: Added frysk.junit.TestCase.brokenIfKernel(int bug, String[] kernels)
Date: Mon, 12 Feb 2007 17:54:00 -0000 [thread overview]
Message-ID: <45D0A9B6.8020108@redhat.com> (raw)
In-Reply-To: <1171282158.3010.5.camel@hermans.wildebeest.org>
Mark,
Obviously, there are two requirements here:
- the need to ensure that all tests are run, and thus recognize regressions
Without this regressions can be unintentionally introduced.
- have a clear baseline - the zero failures - from which to work from
Without this it is never possible for a developer to know if their
change has caused a regression on a specific system
While test-first dogma assumes these are complementary, the realities of
kernel, compiler, and other bugs means this isn't achievable. Some
tests can't pass on some systems and consequently full tests runs are
not normally possible.
The compromise is at least to mark up the tests that can't pass on a
specific system with that information - the brokenXXX flag. Doing this
ensures that:
- zero failures continues as the only acceptable baseline
- no time is lost re-analyzing failures you or I have previously
analyzed or one of our new tests has introduced
Can we work with this?
Andrew
Mark Wielaard wrote:
> Hi Andrew,
>
> On Fri, 2007-02-09 at 19:31 -0500, Andrew Cagney wrote:
>
>> Where a failure is occurring on a specific kernel, try to
>> fix it, or at least mark it up as a known breakage. By doing this,
>> people always have access to a failure free starting point, and with out
>> it, no one is ever sure if their change or existing breakage is causing
>> a failure.
>>
>
> Although I don't mind people blacklisting some tests on their systems
> because of buggy kernel, compiler, libaudit, etc. to make some things
> more convenient for them. I am not sure how maintainable that is. We do
> have explicit tests for broken systems in frysk-import/tests. If a
> developer is working on a system that is know to be broken and buggy
> (because they have frysk-import/tests fail one or more checks) it seems
> that they better make sure to fix the bug in the dependencies and/or
> migrate to a non-broken system. Otherwise they will be running into
> trouble sooner or later anyway. And the skipped tests only paper over
> the problem that will come back and bite them later on during
> development.
>
> Cheers,
>
> Mark
>
>
prev parent reply other threads:[~2007-02-12 17:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-10 0:31 Andrew Cagney
2007-02-12 12:09 ` Mark Wielaard
2007-02-12 17:54 ` Andrew Cagney [this message]
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=45D0A9B6.8020108@redhat.com \
--to=cagney@redhat.com \
--cc=frysk@sourceware.org \
--cc=mark@klomp.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 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).