This is the mail archive of the 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]

Re: Participation in Mauve

Tom Tromey wrote:

> >>>>> "Gerrit" == Gerrit Ruelens <> writes:
> Gerrit> 1.due to the system we are testing, we read files not as an
> Gerrit> RandomAccessFile but by using getSystemResourceAsStream.
> Gerrit> Since this change is made in the SimpleTestHarness this will
> Gerrit> be no cause real problems.
> It might cause problems for our testing.  I'm not positive.

It is no problem to read files as a RandomAccessFile.

> Gerrit> 2.We added an abstract function void setclass(String
> Gerrit> classname) to the TestHarness.
> Do you call this with the name of the class you are testing or the
> name of the class you are writing?  If the latter we could just
> automate this.

the classname is the class you are testing. (the name of the class you
are using to test is known by the SimpleTestHarness )

> Gerrit> 3.We changed the way how checks handle a String message.  All
> Gerrit> those calls are directed to check(boolean b, String msg).  The
> Gerrit> checkPoint method isn't called anymore by those methods
> Gerrit> ... (the checkPoint stays the same)
> Why?

We started changing the SimpleTestHarness so it would be able to generate
output that could be used
to make list of classes that were tested. So we used the verbose option
(we get all the FAIL and PASS).
this was nice but it meant all the information should be passed in the
checkpoint (the name of the class being tested and the method of
the class that is being tested).  But since the class we test is the
same  all through testclas, we added the method setclass to make our life
a bit easier.
I guess I misinterpreted the meaning of passing a string message in a
check ( I tought it should give extra information instead of setting the
checkPoint ).
So we started to use the checkPoint to pass which method we were testing
(with signature).  Unfortunally it meant changing the implementation of
the TestHarness
Finally we used the string we passed to a check to give a message of what
went wrong ...
With all this information we are able to generate output (with "$$" in
the string) which could be parsed (with the grep, cut and sort) to
generate a
file with all the failures and one of what's being tested.  These files
serve as input for a javadoc style program to generate doc pages were is
whether as method is tested or not and if it succeeds al tests (if not it
print a message saying what went wrong).

> Gerrit> 4.We changed the methods which reported the output to the
> Gerrit> screen in the SimpleTestHarnes
> Gerrit> The purpose of points 2 to 4 is to generate a uniform message
> Gerrit> structure.
> This sounds good.  But could we make it a switch?  I'd like the
> default to be something "human readable" (whatever that means -- I'm
> ok with changing the default format if you think it is ugly).
> Tom

It is no problom for us to make our code compliant to the API (basicly
removing one line in each class).
There is no need to change the harness,  it is just a suggestion ...

        Gerrit Ruelens

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