David Winslow ha scritto: > Hey all, I have reached my goal of >40% test coverage for all wicket > modules (hooray!). However, I am not committing the changes in wcs > because I am not happy with the way they are set up. > > In WCS I needed some coverage data so I could query the configuration > for it, so I decided to borrow the data used in wcs1_1 for its tests. > However, wcs1_1 also sets up xmlunit using a relative path to the xml > schemas in wcs1_1/schemas. This relative path fails when trying to run > code using WCSTestSupport from any other module; for now I band-aided it > by copying the schemas directory into web2/wcs. > > I suppose the right thing to do is either make a > MockDataThatIncludesCoverages class that can be used by both, or have > the xmlunit setup code use WCSTestSupport.class.getResource() to get the > schemas in a working-directory-independent manner. Is one method > better/worse than the other?
It's probably better to have a common superclass. What about WCSTestSupport only sets up the coverages, and WCSXmlTestSupport sets up xmlunit as well? Cheers Andrea ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
