> 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?
The book is still underway. Researching the book allowed me to come across several JUnit extensions and utilites, including JUnitDoclet. Thus my suggestion. My understanding is that Clover is available for free for OSS projects. I would expect any of the Keel Founders would be the appropriate folks to register and request a copy. Looking for a OSS alternative to Clover for the book, led me to NoUnit which is targeted at providing code coverage visibility for JUnit tests. I have exchanged several Emails with the main developer and he is very excited about NoUnit. I have added a chapter in the book for those interested in such things who do not have the money to pay for Clover. http://nounit.sourceforge.net/ provides primarily static code coverage, but that would still be very useful for determining how much of the Keel code base has JUnit tests, and where the holes are. Very useful tool - recommended. > 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? There are several Mock object utilities available. Some are specific to a specific API (like EJBs or Struts), and some provide specialized features. The main site for "all things mock" appears to be http://mockobjects.com/wiki/. Which one(s) should be used can only be identified once the actual requirements are specified. In other words, each framework offers something different. > > 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. Checkstyle may be able to do this. I would suggest looking at Jalopy also. Thanks, Derek ===================================== --- The Gunslinger [EMAIL PROTECTED] http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
