Hi,
I was looking again into this topic (since I really need to get
wfsv testing straight) and reviewed the last discussions we
had.
The latest one is here:
http://docs.codehaus.org/display/GEOS/2008/01/16/IRC+Logs%2C+January+15th%2C+2008
The suggestion is to make an AbstractTestData class, extend it into
MockData and LiveData, and have GeoServerTestSupport use AbstractTestData but default on the MockData as an implementation.
Now, looking at the methods in MockData and their usage, I believe the
abstract version would be reduced to an interface, since the only
two methods that make sense for both MockData and LiveData are
setup and teardown?
interface TestData {
setUp();
tearDown();
}
The other public methods in MockData are there to prepare extra
feature types and coverages before the data dir gets written, something
that does not make much sense in a LiveData one that goes and copies
a ready made data directory.
Now, given that some classes do make use of MockData, what about the following:
* we keep GeoServerAbstractTestSupport there, and give it an abstract
TestData getTestData() method (that class now has almost every method
in the old GeoServerTestSupport besides the ones that do setup
the mock data dir)
* GeoServerTestSupport becomes GeoServerMockTestSupport, and declares
a MockData getTestData()
* LiveData by default just copies and cleans a data directory, it will
have to be subclassed in order to run stuff like setup scripts.
* since test subclasses will need to provide the location of the
data directory anyways, I guess they'll just inherit from
GeoServerAbstractTestSupport and implement the getTestData() method
directly.
Finally, a data directory that needs a dbms setup (like the one I need
for wfsv) will probably have a damn slow setup... I'll see what I can
do about that. One obsvious way to get better performance would be
to have a one time setup for read only tests... but as Gabriel
pointed out, we'd need JUnit4 to leverage that...
I think we could keep on using inheritance and just mark the test
methods with the required annotations.
Opinions?
Cheers
Andrea
Hi Andrea,
Looks really good, so I say go for it. I like the breakdown of classes.
Sooner or later we will have to document this, perhaps when we go through it then there may be a few minor things, but I say go for it!! :).
-Justin
Andrea Aime wrote:
Hi,
I was looking again into this topic (since I really need to get
wfsv testing straight) and reviewed the last discussions we
had.
The latest one is here:
http://docs.codehaus.org/display/GEOS/2008/01/16/IRC+Logs%2C+January+15th%2C+2008
The suggestion is to make an AbstractTestData class, extend it into
MockData and LiveData, and have GeoServerTestSupport use AbstractTestData but default on the MockData as an implementation.
Now, looking at the methods in MockData and their usage, I believe the
abstract version would be reduced to an interface, since the only
two methods that make sense for both MockData and LiveData are
setup and teardown?
interface TestData {
setUp();
tearDown();
}
The other public methods in MockData are there to prepare extra
feature types and coverages before the data dir gets written, something
that does not make much sense in a LiveData one that goes and copies
a ready made data directory.
Now, given that some classes do make use of MockData, what about the following:
* we keep GeoServerAbstractTestSupport there, and give it an abstract
TestData getTestData() method (that class now has almost every method
in the old GeoServerTestSupport besides the ones that do setup
the mock data dir)
* GeoServerTestSupport becomes GeoServerMockTestSupport, and declares
a MockData getTestData()
* LiveData by default just copies and cleans a data directory, it will
have to be subclassed in order to run stuff like setup scripts.
* since test subclasses will need to provide the location of the
data directory anyways, I guess they'll just inherit from
GeoServerAbstractTestSupport and implement the getTestData() method
directly.
Finally, a data directory that needs a dbms setup (like the one I need
for wfsv) will probably have a damn slow setup... I'll see what I can
do about that. One obsvious way to get better performance would be
to have a one time setup for read only tests... but as Gabriel
pointed out, we'd need JUnit4 to leverage that...
I think we could keep on using inheritance and just mark the test
methods with the required annotations.
Opinions?
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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,47cd5759305021849620573!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira ha scritto:
Hi Andrea,
Looks really good, so I say go for it. I like the breakdown of classes.
Sooner or later we will have to document this, perhaps when we go through it then there may be a few minor things, but I say go for it!! :).
One more question. About the postgis connection, I'll need to define the
connection parameters somewhere.
Old gt2 way, fixture.properties in svn would be ok?
Or do you want to mimic the new gt2 way of putting a property file in a magic location in the user's home directory (which I never understood/used?)?
Cheers
Andrea
One more question. About the postgis connection, I'll need to define the
connection parameters somewhere.
Old gt2 way, fixture.properties in svn would be ok?
Or do you want to mimic the new gt2 way of putting a property file in a magic location in the user's home directory (which I never understood/used?)?
I think storing it outside of the source tree is nice. So if we could do that i think it would be good. Basically here are the steps:
On test start up look for a file in the home directory called:
<TestName>.properties
If the text exists, read the "fixture", and execute the test. If it does not exist then just skip that test.
I like this approach as we don't have to mess around with profiles and stuff which leads to issues.
-Justin
Cheers
Andrea
!DSPAM:4007,47cd7b1251861137850744!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com