Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>> Hi all,
>>
>> The idea of a datastore compliance test has been kicking around for some
>> time now. The idea is to create an abstract test case which tests all
>> aspects of the datastore api, and then subclass for each data store.
>>
>> Jody implemented such a test for memory data store some time back. I
>> ported the test to postgis and it cleared up a lot of bugs.
>>
>> As part of a recent experiment I have created such a test case, and have
>> three implementations: postgis, shapefile, and property.
>>
>> I would like to create a new module, lets call it "cite", and put all
>> the tests in there. My rational for the new module is that the tests are
>> less likey to get kicked out of the build as somoene is developing in a
>> module.
>>
>> Also having the tests in a single module gives us a quick way to tell
>> which modules are not compliant.
>>
>> What do people think?
> 
> That this approach prevents us from having a coverage report out of these
> tests... also, I don't understand the rationale about being kicked out of
> the build, do you mean that the test module won't be part of the build?
> 
What I meant is that if you look at a lot of the data store pom files,
tests are commented out so they don't run. This often happens as a
result of someone developing on a module and not wanting to deal with
testing. So teh tests temporarily get disabled, never to return.

> So far, modules that have been kicked out of the build were without a 
> mantainer,
> so they were rightfully kicked out in my opinion. The only things that
> makes me think is that, for example, Oracle is an important module and 
> basically
> none of the core developers replaced the missing mantainer, as a result the
> module has been out of the build for long time...
> A choice between releasing without an important module, or releasing with a
> broken one is not easy, but I'd choose with not releasing it, otherwise how
> can we deal with our quality problems?
> If some external project feels that an important module should be back in the
> build, has to go and fix it instead of ignoring the issues...
I could go either way, separate module or not. Both have pros and cons
in my mind. Lets see what others think.
> 
> Cheers
> Andrea
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
> 
> !DSPAM:1004,451809ce107401702038478!
> 


-- 
Justin Deoliveira
[EMAIL PROTECTED]
The Open Planning Project
http://topp.openplans.org

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to