This is the mail archive of the email@example.com mailing list for the Mauve project. See the Mauve home page for more information.
I think mauve is a great idea. I looked at the README file, and am somewhat concerned about this section: ================================================================ You'll notice that each test has a public constructor. This probably seems strange -- why not have the `test' method be static, and justcall it? The answer is that this approach would require java.lang.reflect. The test framework gets the class object for a test using Class.forName. However, making a call to a static method on a class requires reflect. By adding a constructor, we can just call Class.newInstance, and then make a simple method call on the resulting object. This requires a bit less machinery, and more importantly lets us use it for libjava, where we haven't yet implemented reflect. ================================================================ That wouldn't allow me to test JNI compatibility, plus it would allow me to run any of the tests that deal the complexities of the threading and initialization parts. (For instance: what happens if you get an ExceptionInInitializerError in the class whose main() method is invoked, etc.) I would prefer something that would simply diff the expected against the actual output, and voila. It would also be nice if it didn't require anything but /bin/sh to run. On the other hand, I would like it if I could use it to run a group of tests or single tests quickly. That is not to say that test using Class.forName etc. would be useless: in fact, they would probably test durability if the engine isn't shut down between tests. - Godmar