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?
-d
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
Andrea Aime wrote:
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?
I already have a GeoServerWicketTestSupport abstract class which all the wicket UI test classes extend; would prefer to avoid maintaining two inheritance hierarchies for the wicket tests. I will look into pulling out the wicket test methods to a static class though.
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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel