[Geoserver-devel] MockData and GeoServerTestSupport overhaul

GeoServer GeoServer Developer
1

Hi,
I've just finished and committed a refactoring of the MockData and
GeoServerTestSupport that allow for better control of what ends up
being inside the data directory. Basically:
* GeoServerTestSupport provides two new methods, populateDataDirectory
   and getServicesFile() that allow to create a custom data directory
   and use a custom services.xml file.
* MockData sports addStyle, addPropertiesType and addCoverages methods
   that can be called to configure a new style, a new property datastore
   and a new coverage. Alternatively, one can call addWellKnownTypes
   to configure the well know cite feature types (just like the old
   MockData did). After that, the setUpCatalog method will write down
   a catalog.xml file with all the feature types and coverages that
   have been configured so far. (GeoserverTestSupport already does
   this so no worries, it's useful only if you need to customize
   your data dir).
* MockData now writes the mock data directorys to target/mockXXXXdata
   instead of using the default temp directories. This helps windows
   users like me to avoid having 10000 mock directories in the
   temp, since under windows the mock directory is not cleared up
   (and it's not cleared up on linux either if you're debugging
    a test and stop it before it reaches the tearDown).
   Now every time a mvn clean is run all old data directories will
   be wiped out.

I think we should really setup a documentation page describing how
to use mock testing in geoserver... oh well... I'm too busy
to do it right now, but I've scheduled an issue to do so:
http://jira.codehaus.org/browse/GEOS-1520

Cheers
Andrea

2

Cool, nice work Andrea. Comments inline.

Andrea Aime wrote:

Hi,
I've just finished and committed a refactoring of the MockData and
GeoServerTestSupport that allow for better control of what ends up
being inside the data directory. Basically:
* GeoServerTestSupport provides two new methods, populateDataDirectory
   and getServicesFile() that allow to create a custom data directory
   and use a custom services.xml file.
* MockData sports addStyle, addPropertiesType and addCoverages methods
   that can be called to configure a new style, a new property datastore
   and a new coverage. Alternatively, one can call addWellKnownTypes
   to configure the well know cite feature types (just like the old
   MockData did). After that, the setUpCatalog method will write down
   a catalog.xml file with all the feature types and coverages that
   have been configured so far. (GeoserverTestSupport already does
   this so no worries, it's useful only if you need to customize
   your data dir).

So by default all the "standard" feature types are added in
GeoServerTest support? But the test can override and just add the types
it wants if need be?

If I could give one bit of feedback it would be to change the name of
"addPropertiesType" to just "addFeatureType". If you want to make
properties evident maybe "addFeatureTypeFromProperties". This leaves the
door open for other datastores like "addFeautreTypeFromH2" or something.

Wait... can we scrap that and just call it "addWWW"? :stuck_out_tongue:

* MockData now writes the mock data directorys to target/mockXXXXdata
   instead of using the default temp directories. This helps windows
   users like me to avoid having 10000 mock directories in the
   temp, since under windows the mock directory is not cleared up
   (and it's not cleared up on linux either if you're debugging
    a test and stop it before it reaches the tearDown).
   Now every time a mvn clean is run all old data directories will
   be wiped out.

Cool, nice fix!! Never thought of that.

I think we should really setup a documentation page describing how
to use mock testing in geoserver... oh well... I'm too busy
to do it right now, but I've scheduled an issue to do so:
http://jira.codehaus.org/browse/GEOS-1520

Great!! This has been something i have been wanting to do but have been
waiting until our developer docs become a priority, which for a long
time they have not... With the batch of developers that have shown up
lately it may be wise to reconsider this.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,474bfa25281822092453641!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

3

Justin Deoliveira ha scritto:

Cool, nice work Andrea. Comments inline.

Andrea Aime wrote:

...

So by default all the "standard" feature types are added in
GeoServerTest support? But the test can override and just add the types
it wants if need be?

Yes. For example, in WCS tests I only add coverages, no time wasted
trying to load up feature types I'll never use.

If I could give one bit of feedback it would be to change the name of
"addPropertiesType" to just "addFeatureType". If you want to make
properties evident maybe "addFeatureTypeFromProperties". This leaves the
door open for other datastores like "addFeautreTypeFromH2" or something.

Right, that was the idea, since I see h2 datastores coming in for testing stuff like xlink and complex features.

Wait... can we scrap that and just call it "addWWW"? :stuck_out_tongue:

Nah, addWWWFromProperties please :slight_smile:

I think we should really setup a documentation page describing how
to use mock testing in geoserver... oh well... I'm too busy
to do it right now, but I've scheduled an issue to do so:
http://jira.codehaus.org/browse/GEOS-1520

Great!! This has been something i have been wanting to do but have been
waiting until our developer docs become a priority, which for a long
time they have not... With the batch of developers that have shown up
lately it may be wise to reconsider this.

Indeed it would :slight_smile:
Cheers
Andrea