This is the mail archive of the mauve-discuss@sourceware.cygnus.com mailing list for the Mauve project. See the Mauve home page for more information.
Anthony Green wrote:
>
> Artur wrote:
> > 1) I cannot check out latest mauve (cannot connect to cvs server)
>
> Can you give me details? (is it a cvs issue, or networking issue?) I
> think if might be a good idea to make nightly tar-balls. Does anybody
> think this is a bad idea?
I think that it is problem with network. We still have quite bad inet
here in Poland, so I would blame it, but I was able to checkout japhar,
egcs or classpath changes at same time. Mauve and kaffe server were not
answering - cvs was just doing nothing around for many minutes. I wasn't
able to update kaffe sources also, so maybe it is fault at my side of
network.
> > 2) I'll convert it when it will be ready and working - until then it
> > is easier to debug it in this form
>
> Ideally the simple framework supplied with the Mauve testsuite is
> suitable for both (a) developing new test cases and (b) running the
> entire suite. Do you have any suggestions for making (a) any easier?
> It is, perhaps, a little tedious having to give the testlet names as
> standard-in. Maybe we could support both standard-in _and_ command
> line args?
Why not in mauve framework ?
1) I use jbuilder for this particular class (because of very fast
compile/error/correct/run turnabout). Mauve depends on magic shell
scripts. I prefer to run in windows because I have 4 JDK versions here,
with only one at linux (other thing is that linux has also kaffe and
japhar, but they are not stable enought for me to build test on them)
2) I prefer fully verbose error messages. Of course I could add
checkPassed() and checkFailed(message) methods to TestHarness, but this
would give only
"test 123456 of 12376317327 failed"
in addition to my messages, which would just garble output
3) It is easier to manipulate file in top level package. People can run
this test anywhere without setting it up inside mauve
Of course, when it will be working, I plan to change it to mauve
framework. I suppose that it will require changing all
System.out.println to string operation with call to checkFailed(message)
and adding
else
{
harness.checkPassed();
}
after each
if (test) {...fail...}
BTW do you want to build something on top of TestHarness in future ? I
mean if it is important that every atomic test have its number. If not,
then it will be easier, as each test could just call one pass/fail
method at end (in addition to possible checkpoints for unxpected
exceptions). I'm not sure for what such number could be used, but maybe
some bug database ? In that case it would have to stay the same between
mauve releases....
Artur