I have been out of pocket for a bit and wanted to get started again... testing coverage was the last thing I felt that I could contribute the most on.
To start with, I am looking to create/integrate test cases for package substitution and some of my bean info creation work that I did.
Any thoughts would be greatly appreciated. Maybe we could get some stuff out in the open before everyone checks out for the holidays.
thanks, ryan
Ryan Ovrevik wrote:
I think that these tests accomplish more than simply regression testing.
It would be great if the test support was really a means to create a "satisfying test-first experience" (from xp). Where the tests are used during every iteration of the code, compile and run cycle.
Honestly I think most developers would be perfectly productive in either structure. The only thing that matters is that the iterative development cycle is satisfying.
As for as a volunteer to get this moving... I'm in. Although, I need assistance on the b) and c) that you described. I could play the role of the integrator for those parts if that helps?
Ryan
Rupp, Heiko wrote:
Hi,
something that I have in mind for some time now and where I got reminded by Ryan Ovrevik <http://opensource.atlassian.com/projects/xdoclet/secure/ViewProfile.jspa?name=rovrevik> in XDT-1002 and others is regresion testing.
I basically see three cases:
a) make sure that generated code compiles (and would even run)
b) validate the generated xml - against a DTD and some reference xml
c) let the developer validate the written .xdt files without running against a test case
The first part is easy for a) just add a compile step into every build of a module. The second part could mean to run findbugs(*1) against the generated code and make
sure, that there are no prio 1 errors.
Same for b) the first part is done within the samples directory. But this doesn't tell
me if a change in some .xdt will leave out some elements/attrbutes, but shouldn't as
long as the DD ist still valid.
c) is only caught when running the samples _and_ the sample needs the specific .xdt
file, which takes quite some round trip time.
Obviously the first two are more things for an ant task, while the latter would be an interactive
thing.
The other thing is layout of tests. There are already some unit tests in core. Should
unit tests follow this and have a test directory under each module? Or should it follow
the samples case with a new 'toplevel' directory, where all test go into (I am in favour of that)?
Is junit the right framework for all this? Are there better ones? Suggestions? Opinions? Volounteers?
Heiko
(*1) http://findbugs.sf.net/ <http://findbugs.sf.net/>
------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
