Justin Deoliveira ha scritto: > 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.
This is the kind of coding approach we should battle against, unit tests are either developed along with the code, or not at all (or very poorly anyway, as an afterthought). >> 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. Hum, so your idea is that given that this module will be owned by someone else's than the datastore developer, so even if they do remove their module from the big test, someone else would notice... yeah, kinda like that. My only big fear is that since code coverage could not be measured this way, people will find in it an excusive for lousy levels of testing... 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
