This is the mail archive of the
mailing list for the Mauve project.
Re: Reading Writing and Support Classes
- To: email@example.com
- Subject: Re: Reading Writing and Support Classes
- From: Anthony Green <firstname.lastname@example.org>
- Date: Thu, 18 Feb 1999 20:44:50 -0800
- CC: email@example.com
- References: <199902190423.XAA29516@melange.gnu.org>
> I run into new design questions every time I write a test it seems.
You're just pushing the envelope! :-)
> 1). The resource framework is great for reading, but what should we
> do about tests that need to write? It seems to me that some
> environments might be read only, so we don't want to run these mixed
> in with everything else. I separated them into separate files.
> Also, do we want to worry about which directories we are writing to?
The resource framework is useful for reading support data (the unicode
stuff, for instance). My feeling is that for tests that really
require File support, we should tag them with something like
HAVE_File. HAVE_File can be set by default in the choose script, and
then implementations that don't support File stuff just !HAVE_File.
Or something like that.
As for directories... it seems like the testlet should ask TestHarness
for a directory name. The name can either be passed on the command
line, or set during configuration. I kind of think that we should
have a SimpleTestHarness.java.in, and then set the srcdir and temp dir
at configure time. What do you think?
> 2). I noticed Tom split some of my things into support classes to avoid
> having multiple classes in the same file. When I do this, my support
> classes don't get built because they don't have a Tags: line that is in
> scope. What am I doing wrong? As a workaround, I tagged them with the
> appropriate tag for building them (eg. JDK1.0) and changed SimpleTestHarness
> to skip over anything that isn't an instance of Testlet (which it probably
> should be doing anyway). I actually kind of like my solution.
Support classes are tagged with `not-a-test'.
If testlet Toga uses support class Foo - it has a...
// Uses: Foo
This gives the choose script a little more control over what exactly
gets built. For instance, if Toga is excluded from testing then Foo
won't get built.
Anthony Green Cygnus Solutions