This is the mail archive of the
mauve-discuss@sources.redhat.com
mailing list for the Mauve project.
Re: Some issues..
Thomas Zander writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thursday 29 April 2004 17:28, Andrew Haley wrote:
> > Thomas writes:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > On Thursday 29 April 2004 13:39, Andrew Haley wrote:
> > > > I don't see the problem, really. ?If it doesn't run on some system,
> > > > what is lost? ?All that happens is a few test failures.
> > >
> > > For most test environments I make the whole build fail as soon as a
> > > test fails; this is implemented in the ant-based mauve test as well.
> > > The reason for this is simple; if a test fails its a regression bug;
> > > you can't commit changes while you have a regression bug.
> >
> > Okay, but if you're going to insist on this you need a way to mark
> > known/expected failures: does any VM pass everything? So, why not
> > mark this whole thing as "known to fail" on Windows and move on?
>
> There are 3 approaches to this; I'd suggest the first for ease of use..
> 1) check in the test (or even in the test-framework) if a system setting is
> present.
> If(System.getProperty("os.name").equals("Windows")) return;
This sounds not entirely unreasonable, but there is one disadvantage:
if the Win system has a working shell, it seems a shame not to run
this test. But in this case it's probably not important one way or
the other: if the Runtime.exec() fails, you can just return. It's
really only gcj that needs these tests as far as I am aware.
Andrew.