Geir Magnusson Jr <geir <at> pobox.com> writes: > I think we should certainly be using Muave for testing. However, that > doesn't remove the need for our own unit tests to be testing > implementation internals.
Completely agree. Tests of implementation internals don't belong in Mauve of course. I guess the question is whether, when a Harmony contributor wants to write a test for documented, public, specified API functionality, should that test go in Mauve instead of Harmony's own test framework? Obviously I'd argue that it should, as then it benefits all implementations, not just Harmony. Plus if Harmony contributors are running Mauve regularly, they're getting the benefits of Mauve tests contributed by developers of other implementations too. (I've watched people go down this road before: I was following several projects with independent class library implementations years before there was any prospect of them merging into Classpath as they've now done. Even when there was no cooperation on the library code, everybody seemed to agree it was in their best interests to collaborate on the test suite...) If it *is* recommended for Harmony contributors to put such tests into Mauve, that recommendation probably ought to be mentioned in answer to questions like the one that I replied to; the original poster didn't say whether their tests were going to be of implementation internals or not... > Would you like to help us get it working in our build/test framework? I'm afraid you're asking the wrong person: I can't get Mauve working at all... Stuart.
