This is the mail archive of the
mailing list for the Mauve project.
Participation in Mauve
- To: mauve-discuss at sources dot redhat dot com
- Subject: Participation in Mauve
- From: Gerrit Ruelens <gerrit dot ruelens at acunia dot com>
- Date: Mon, 05 Feb 2001 16:30:38 -0500
- CC: tromey at redhat dot com, chris dot gray at acunia dot com, steven dot buytaert at acunia dot com
Here at ACUNIA we are using the Mauve suite to perform tests on our vm
and use the framework to write new tests. We would like to contribute
our effort back into Mauve project, but along the way we slightly
altered the TestHarness and ended up with an altered SimpleTestHarness.
1.due to the system we are testing, we read files not as an
RandomAccessFile but by using getSystemResourceAsStream. Since this
change is made in the SimpleTestHarness this will be no cause real
2.We added an abstract function void setclass(String classname) to the
3.We changed the way how checks handle a String message. All those
calls are directed to check(boolean b, String msg). The checkPoint
method isn't called anymore by those methods ... (the checkPoint stays
4.We changed the methods which reported the output to the screen in the
The purpose of points 2 to 4 is to generate a uniform message structure.
It is build with the following rule:
<result> $$<classname>$$<checkPoint>$$<String message>$$ <file name>:
<checkPoint> (number <count>)
<result> PASS or FAIL (nothing changed here)
<classname> is the class you want to test (set by setclass)
<checkPoint> indicates the method that is being tested ( set by
<String message> is de string you pass to the check method (or default
this message could be description of the test.
<file name> is the name of the java class being used ...
<count> is still the number of checks after a checkPoint ...
This could lead to the following example:
FAIL $$java.lang.String$$toString()String$$wrong value returned$$
gnu.testlet.java.lang.String: toString()String (number 4)
this structure serves for two purposes:
1.if you run a lot of tests you get a nice overview of what is going
wrong. (class, method, description of test)
2.but more important this string can easily be parsed to generate a nice
It is not that hard for us remove all the setclass function calls in our
code (one line in each test class ), but I feel it might be useful to
have such a method.