[jdom-interest] TestCase_Attribute

[philip.nelson at omniresources.com]

> I'm going through another interation of the autogeneration 
> code which will
> create interfaces rather than concrete classes, however you 
> code will move
> over very easily.

No doubt.  What is the purpose of the interface?  The one area I can see is
that you can rerun the generator without trashing your original code, a good
thing.  Maybe you should add  a way to specify methods to ignore and
additional ones to add.  The current generator saves some coding for the
public interface of each class but ignores the use case of a test needed to
prove that *sequence* of method calls works, particularly when state
changes.  I explicitly avoided sharing an instance of my test attribute to
avoid any possible errors because of leftover state from earlier method
calls.  There are probably times where I might want to add tests that don't
relate specifically to a single method.  How would I add these to the test
suite?  Would the test suite get the methods to call from the interface or
the class?

There is still the issue of generating noop methods.  What do you think
about the wait, notify methods etc.?  If we don't want them, they shouldn't
be added because to me, I wouldn't want a test run that doesn't have any
assertions in it. It would be nice if junit supported a warning so that it
would warn you of a test that was yet to be implemented.

Considering the fact that you are going back and rewriting a test generator,
an second option would be to simply write the test cases and be done with it
;^)  I do worry that the  use of test cases may be hampered a little by the
test generation process.  To add or change a method in a jdom class,
Brett/Jason/Elliotte would have to:

make the change, 
run the generator, 
compile the interface, 
go to the test case class, 
add/change the method 
compile 
and the run the test.  

Without the interface it's 
add/change the method, 
go to the test case class, 
add change the method 
and run the test.

The spirit of JUnit seems to be that the programmer is the one writing the
unit tests.  In this case, we are helping out by jump starting a test suite
for them but ulitimately, it is the programmer of jdom classes that should
modify the test suite as changes/additions to JDOM are made.  What do you
think?