Examples: 1. http://jakarta.apache.org/poi/tests/junit/ - unit test report for POI 2. http://cvs.apache.org/viewcvs/jakarta-poi/src/testcases/org/apache/poi/hssf/record/ - some unit tests
(see root src/testcases for more) I started out very skeptical that it was worth the effort, but as our structures changed code that had unit tests never made it into CVS broken, code that didn't well took sometimes days to track down. We've gone a step further and started generating some code from XML descriptors including unit test data: http://cvs.apache.org/viewcvs.cgi/jakarta-poi/src/records/definitions/ http://cvs.apache.org/viewcvs.cgi/jakarta-poi/src/records/styles/ We can now generate the low level record types along with their test case using real world data. This descriptor method mostly just saves us typing (and boredome) but also ensures we do things the same way every time. For another part of the project we're doing the same thing but subclassing the "Type" for adding specific logic (and I assume we're doing the same for the test case). In conclusion The biggest advantage of unit testing is in preventing those multiday bugs that creep up in dependencies. Further advantages can be reached through autogeneration of simple types and their test cases. Over time this has proven itself at least on POI to be the most invaluable thing we do. (the second is whine at people if they don't document ;-) ) -Andy On Sat, 2002-05-18 at 11:16, Ross Gardler wrote: > > > David Crossley wrote: > > > Is "unit testing" different to "functional testing", or are they > > complementary? > > > They are indeed complimentary. In a nutshell, unit tests ensure that the > indiviviual methods within individual classes behave as expected. > Funtional tests ensure that the system as a whole behaves as expected. > In other words, unit tests operate on classes (in many cases individual > methods), functional tests will emulate a user actually using the system > as a whole so operate on combinations of classes. > > > > Here are a few relevant Anteater threads ... > > > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101831758001240 > > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102168000122016 > > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101897525908787 > > Thanks, I will look into Anteater (took a brief look the other day, > looks like good stuff). > > > > > > You mention something above that could be key ... if only > > unit tests were interesting. I wonder if Cocoon could help > > itself here. If the results of running the test suite were generated > > as xml, we could have a Sample that demonstrates how happy > > Cocoon is with its current state. > > > JUnit (the most popular unit testing tool, http://www.junit.org)) does > indeed export its results in XML format. There are also lots of tools > that will show how much code is covered by the tests. It would certainly > be possible to create some nice reports showing how well the code is > tested. > > > The developers would like to > > be sure that their favourite classes were behaving well. > > > So what do other developers think of this. Is it worth the effort? Will > you take responsability for improving the test coverage of your code if > given suchg reports? > > Ross > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
