From: Maurice van der Pot <griffon26@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] tests
Date: Tue, 1 May 2007 19:18:28 +0200 [thread overview]
Message-ID: <20070501171828.GL10636@kfk4ever.com> (raw)
In-Reply-To: <200705011508.57220.peper@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]
On Tue, May 01, 2007 at 03:08:56PM +0200, Piotr Jaroszyński wrote:
> Firstly each test can be(not all categories are mutually exclusive):
> - not existant
> - non-functional
> - not runnable from ebuild
> - useful but unreasonable resource-wise
> - useful and reasonable resource-wise
> - necessary
> - known to partially fail but with a way of skipping failing tests
> - known to partially fail but with no easy way of skipping failing tests
> Is that list comprehensive?
Isn't it easier to list a set of boolean properties of _individual_
tests?
- We don't need "non existent".
- Non-functional and known to partially fail come down to "known to
fail" for individual tests.
- I have no idea what "not runnable from ebuild" is.
- Unreasonable could be "resource hungry" or "needs additional deps"
(those are two different things).
- If a test is "necessary" I don't see why we should allow it to be
skipped.
- And about skipping failing tests. There is always a way to skip
failing tests: not running any of them. It's just the granularity that
is different, but the user doesn't care about that.
> Secondly we must answer the question how precisely we want to distinguish
> them, so users/dev can choose which categories of tests they want to run.
> What comes to mind is:
> - run all tests
> - run only necessary tests
> - run only reasonable tests
> - don't run tests at all
> Again, is that list comprehensive?
I'd say, let the user decide based on the properties, fex:
run known to fail : no
run resource hungry: yes
run additional deps: no
if ( (known to fail == false || run known to fail == true) &&
(resource hungry == false || run resource hungry == true) &&
(additional deps == false || run additional deps == true) )
{
run the test
}
So for each test/set of tests and for each possible reason not to run
it, either the reason does not apply to this test or the user explicitly
said to run it anyway.
You don't see the "way of skipping failing tests" in this last part.
This is because if the decision is made not to run a test, the smallest
set that can be skipped (possibly all tests for an ebuild) are skipped.
> Please don't post solutions unless we figure out which options we really want
> to deliver.
I'm sorry if this counts as a solution, but I wasn't sure the list you
gave was the kind of list we need and I didn't know another way of
explaining the use of the properties I listed.
Regards,
Maurice.
--
Maurice van der Pot
Gentoo Linux Developer griffon26@gentoo.org http://www.gentoo.org
Creator of BiteMe! griffon26@kfk4ever.com http://www.kfk4ever.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-05-01 17:21 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-01 13:08 [gentoo-dev] tests Piotr Jaroszyński
2007-05-01 13:24 ` Josh Sled
2007-05-01 13:32 ` Ciaran McCreesh
2007-05-01 15:50 ` Alec Warner
2007-05-01 16:04 ` Daniel Gryniewicz
2007-05-01 16:23 ` Vlastimil Babka
2007-05-01 17:18 ` Maurice van der Pot [this message]
2007-05-01 17:35 ` Ciaran McCreesh
2007-05-01 19:53 ` Maurice van der Pot
2007-05-01 20:05 ` Piotr Jaroszyński
2007-05-02 5:58 ` Rémi Cardona
2007-05-02 6:53 ` Danny van Dyk
2007-05-01 21:52 ` Josh Saddler
2007-05-01 22:31 ` Stephen Bennett
2007-05-01 22:28 ` Josh Saddler
2007-05-01 22:47 ` Piotr Jaroszyński
2007-05-01 23:08 ` Ciaran McCreesh
2007-05-01 23:06 ` Ciaran McCreesh
2007-05-01 17:58 ` Piotr Jaroszyński
2007-05-01 19:24 ` Rémi Cardona
2007-05-01 20:10 ` Jure Varlec
2007-05-01 22:06 ` Robin H. Johnson
2007-05-01 20:25 ` [gentoo-dev] tests Piotr Jaroszyński
2007-05-01 23:32 ` [gentoo-dev] tests Marius Mauch
2007-05-01 23:46 ` Daniel Gryniewicz
2007-05-01 23:55 ` Ciaran McCreesh
2007-05-02 0:34 ` Brian Harring
2007-05-02 11:52 ` Ciaran McCreesh
2007-05-02 0:08 ` Robin H. Johnson
2007-05-02 0:12 ` Stephen Bennett
2007-05-02 1:51 ` Daniel Gryniewicz
2007-05-02 6:49 ` Danny van Dyk
2007-05-02 11:56 ` Ciaran McCreesh
2007-05-01 23:56 ` Ciaran McCreesh
2007-05-02 10:54 ` Philipp Riegger
2007-05-02 20:05 ` Mike Frysinger
2007-05-02 20:12 ` Ciaran McCreesh
2007-05-06 8:39 ` Mike Frysinger
2007-05-05 21:17 ` [gentoo-dev] tests Ryan Hill
2007-05-06 4:27 ` Alistair John Bush
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=20070501171828.GL10636@kfk4ever.com \
--to=griffon26@gentoo.org \
--cc=gentoo-dev@lists.gentoo.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