Hi,
lately I've been having quite a bit of troubles in the WFS versioning
module. The reason is simple, I cannot unit test it because we don't
have a "versioning property datastore", that is, a datastore that
makes no assumptions on external software installed on the machine.
Soo, it seems I need some way to test using the postgis versioning
datastore. This means I need:
* a way to check a certain postgis datastore is available on the
machine (so that I can skip the test if it's not there)
* a way to create a data directory using that datastore
* a way to run setup and cleanup scripts so that I can trust
the initial state of the db
The gt2 do something similar in jdbc datastores by making use
of a property file. They then build a connection by hand and run
whatever sql is needed directly from code.
Now, the current testing base class (GeoServerTestSupport)
provides testing convinience methods I need to keep
(methods to execute a post call and parse the results into
a DOM, for example), and a direct reference to MockData
class, that I want to remove.
So what I propose is to move MockData usage in a subclass,
GeoServerMockTestSupport, and leave the base class emtpy with
regards to how the data dir is setup. The base class would
become abstract with a template method to gather the actual
location of the data dir.
This way I can create another subclass that takes care of using
a predefined data dir instead and do the above.
To recap, I make a new GeoServetTestSupport with an abstract
method String getDataDirLocation(). I create a GeoServerMockTestSupport
that uses MockData and instantiates it in getDataDirLocation(), and
this class becomes the new base class of all existing unit tests.
Finally, I'll create in the WFSV module a new subclass allowing
the usage of the postgis versioning data store.
The idea is to store a minimal but working
data dir as a test resource, parse catalog.xml (with XMLConfigReader)
in order to gather the connection params,
test the db is there, run programmatically an sql script, and
then start up the mock geoserver for testing (the sql
script should take care of dropping the tables before re-creating
them, so that we have a single sql script).
After that, we set the test data dir path into the servlet
context and we start up the unit testing.
The data dir could be used as is, without being copied, since
no one of the tests really need to modify it (the wildest
tests may need to alter the in memory representation, but not
to actually change the stored config).
What do you think? Seems simple enough. If we want a more
abstract superclass could be used to allow doing the same
kind of testing against Oracle or Postgis (should we ever
stumble into a datastore specific issue we don't feel
comfortable unit testing in gt2 only).
Cheers
Andrea