This is the mail archive of the mauve-discuss@sources.redhat.com mailing list for the Mauve project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Participation in Mauve


Hi,

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
problems.
2.We added an abstract function void setclass(String classname) to the
TestHarness.
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
the same)
4.We changed the methods which reported the output to the screen in the
SimpleTestHarness

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>)

where:
 <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
checkPoint)
 <String message> is de string you pass to the check method (or default
"no Message")
  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
report.

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.


 Gerrit Ruelens




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]