Re: [patch] minimal test case for sha-1 and md5

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:

Andrew> In this particular case, I want message digest tests in the libgcj
Andrew> testsuite because they test important system components and are also
Andrew> an excellent test of the compiler.

I agree with this principle when the test case shows a compiler bug
that manifests either on the test case itself or on the library bug
the test case invokes.  To me this makes sense because such tests
aren't library bugs per se, and putting random gcj regression tests
into mauve doesn't help most mauve users.

For instance, we've really benefited from having a StreamTokenizer
test in our repository, since that has caught a lot of regressions in
the force-evaluation-order code.

OTOH, when we have an ordinary library bug, in my opinion the test
belongs in mauve.  My reason for wanting this is that I think there is
limited energy for writing tests (who wants to write them twice?), and
I think we gain a lot by cooperating with other projects.  So, unless
the test has some special meaning to us beyond "another library oops",
it is friendlier to cooperate.

IMO the big picture for testing is that we would like Mauve, Jacks,
plus various other bits floating around, to congeal into a TCK-killer.
(That's probably a story for a different list.)

There are probably limits on how many tests we can reasonably put
directly in libjava.  So we have to be a bit choosy about which tests
go in.  E.g., if a front end patch fixes a Jacks failure, I generally
don't write a separate test case for it (on the theory that anybody
hacking the front end ought to be running Jacks).

Alternatively, if there aren't limits, we can put a whole copy of
Mauve and Jacks in there.

Tom