Adam Young writes: > Hi, I'm the guys that joined recently and claimed he would implement > the javax.security.auth packages. As I've dug through the volumes of > info, the public Java docs, and the messages about what was or wasn't a > good way to approach coding I've come up with a plan. Before I go down > this path, I'd like a little validation. > Since I can't look at the Sun code, I'm trying to find a way to make a > test that the new Classes I implement do the same thing as the > original. I've started with > > javax.security.auth.Subject. > > Along with this is implementations of AuthPermission and > SubjectDomainCombiner, all written just referring to the official > Javadocs and a couple books I have on Java Security. I would like > to write a test ala JUnit or Mauve. If I write this Test in > Eclipse, and use its automatic code generation facility to read the > Sun Version of the Subject class and write delegation code within a > class, I will at least have a comprehensive list of all the public > methods in the interface. This simplifies my test to making sure > that all these methods work. Is this Kosher?
It seems to me that the list of public methods in a class file is part of its published interface, and thus is probably legit. However, I question the need to do this. You have online Javadocs for all the public methods. > If I write a Test against the Sun implementation, and then rewrite my > implementation until that Test runs, should this test then be added to > Mauve? Yes. But please don't simply assume that Sun's implementation is correct: we code to the specification. not the implementation. > Has anyone used the Mauve framework to write unit test other than for > Classpath? Is there a Test framework portion of the code separate from > the Testlets defined for testing Classpath? I don't understand this question. Mauve works with any Java library. Andrew. _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
