Derek, > I would suggest taking a look at http://junitdoclet.org/ > for a tool that might help retrofit the existing codebase > with the JUnit "wiring". The tests will still have to be > added but JUnitDoclet helps with most of the mundane parts. > I will be attempting to add unit-tests to some of the existing code. I know you were contemplating writing a Junit book sometime back, your suggestions and help in this area are most welcome. Clover is a commercial tool, do you know of anything similar in the OSS world that will identify test-coverage holes? Or, maybe we can please with Clover folks to donate a license to us? Could you help us with a brief guideline (on Wiki, possibly) that would recommend what, how to test in Keel?
One thing some of us have talked about was using stubs or mock objects for other services that the service under test depends on. Are there any guidelines, tools available to help with that? > Something will need to be developed as a checker to handle > whatever is defined as "minimal" for JavaDoc. Any ideas on > how to handle this? > By minimal, I was thinking that at least the public constructors, methods, fields and the class itself would need to be documented. Can checkstyle provide the checking for us? I think checkstyle can be invoked from a CVS trigger: so, upon commit, we could check for Javadoc, as well as reformat the code to some (to be determinded) coding standard. Shash http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
