This is the mail archive of the mailing list for the Mauve project. See the Mauve home page for more information.

[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]

Re: Classpath Test Contents

>>>>> "Aaron" == Aaron M Renn <> writes:

Aaron> Below I'm attaching an outline of the contents of our
Aaron> test package.  As I said eariler, it basically prints a line
Aaron> that starts with "PASSED:" for a passed test or "FAILED:" for a
Aaron> failed test. Some tests just print output and it is up for you
Aaron> to see if it looks right.

I converted a couple Classpath tests today -- the two java.beans
tests.  These should give an idea of what the tests end up looking
like (one I rewrote extensively, but the other is fairly similar to
the original source).

I'd prefer to see the imported tests use the `check' method on the
harness instead of printing pass/fail by themselves.  That lets us
play games with the harness when appropriate.

Maybe it's time to solve the "expected output" problem.  We could add
a new `check (String)' method that would check the output to
System.out against the given string.  Then we'd just have to change
the test harness to override System.out before each test run.


Do any of your tests rely on reading a pre-existing data file?  If so,
we'll probably want to make it possible for the test cases to find the

Aaron> How do you want me to put it in?  It looks like the existing
Aaron> tests have a subdirectory per class tested, but I've got some
Aaron> files that test multiple classes.

If it's possible, split them up.  Of course, it probably isn't
possible to really test single I/O classes in isolation.  Still, give
a good try at categorizing, when possible.  Being able to (de-)select
on a class-by-class basis is an important feature of the test suite.

Especially important is segregation by JDK version number.  E.g., try
not to require JDK1.2 functionality in a test that tests something
introduced in JDK1.0.