Re: [Geotools-devel] epsg-hsql, DefaultDataStoreTest

[Jody G. <jga...@re...>]

Martin Desruisseaux wrote:
> Jody Garnett a =E9crit :
>> Jesse was talking to me about that the other day, apparently the=20
>> change to use the sample-data module as the
>> source of all resources has slowed down the shapefile tests a lot. =20
>> Apparenlty he needs to copy the files out of the
>> sample data module and into a temp file again and again and again ...
> I think that he need to copy the files because the shapefile module=20
> uses java.nio and cant't work with a java.io.InputStream.
Indeed, nio (and memory mapped files) is often where the pain was.
> But if the copy is performed using org.geotools.TestData.copy(...),=20
> then the copy should be performed only if the file does not already=20
> exists. If a copy is required, the copied file is stored in the=20
> "<module_to_be_tested>/target/classes" directory. This means that the=20
> copies is performed again only after a "mvn clean".
very cool! it could be that changing to this method will fix the problem=20
for shapefile testing.
> Looking again in the source code, just realized that my previous=20
> paragraph is not quite true because there is a "deleteOnExit" call at=20
> TestData:163. If we remove that line, my previous paragraph should=20
> become true.
Interesting tradeoff - if we remove it then we get a speed improvement.=20
But we lose test isolation. Wonder if we can make an additional method=20
called "TestData.temp( ... ) that has the deleteOnExit call. This can be=20
used when writing tests that modify the data set.

In terms of usability we may also wish to do some helpful magic of the=20
form ...
TestData.temp( "foo.shp" ); // copies foo.* in one go ... foo.prj, =20
food.dbf etc...

>> A different way to look at the problem would be how can we slurp all=20
>> the resources out of sample-data once, and take this
>> responsibility away from those testing plug-ins?
> Not sure I understand what you means... You means move back the test=20
> files in the modules that use them? But we centralized them in=20
> sample-data because we had a fair amount of duplication. The same=20
> files are used in many modules.
What you describe above with Test.copy( ... ) is better then what I had=20
in mind. I was thinking of extracting the all the resources in=20
sample-data once, and then letting the tests go to town (and let them=20
take responsibility for making temp copies that delete on exit if they=20
are making modifications.

Jody