|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
|
|
Using coverage dataHey 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 ------------------------------------------------------------------------- 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@... https://lists.sourceforge.net/lists/listinfo/geoserver-devel |
|
|
Re: Using coverage dataDavid 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 Geoserver-devel@... https://lists.sourceforge.net/lists/listinfo/geoserver-devel |
|
|
Re: Using coverage dataAndrea 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? > > 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@... > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------- 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@... https://lists.sourceforge.net/lists/listinfo/geoserver-devel |
| Free embeddable forum powered by Nabble | Forum Help |