This is the mail archive of the firstname.lastname@example.org mailing list for the Mauve project. See the Mauve home page for more information.
>>>>> "Aaron" == Aaron M Renn <email@example.com> writes: Aaron> Below I'm attaching an outline of the contents of our java.io 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. Thoughts? 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 srcdir. 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. Tom