Andrea Aime wrote: > However, I'm not really sure it should be the developer to decide > whether the server is under his control. It's usually > only the maven user that knows. > Say I want to setup unit testing against ArcSDE. The developer > has full control over his own instance, he would like to use > FixtureTestCase then. But the continuous build admin has to > use a remote SDE instance he has no control over, > he would like to use OnlineTestCase then. Casting the decision > into code does not allow to satisfy both. > What about having just one class, OnlineTest, that reads from > the property file a flag (skip.on.failure=true), which allows > the end user to control what behaviour is the desired one, > fail fast, or skip and complain on logs?
Good point. The behaviour should be configurable by the end-user. Should the default setting be skip.on.failure=true, preserving the existing (but pointless) behaviour of OnlineTestCase, or skip.on.failure=false, the normal behaviour expected of a unit test? With skip.on.failure=true, OnlineTests that pass will allow the build to continue, whereas OnlineTests that fail will allow the build to continue. When I find unit tests that don't test anything, I delete them. An OnlineTest with skip.on.failure=true might as well be disabled because it does not test anything (in its connect/disconnect). The continuous build admin can prevent annoying build failures by removing the fixture configuration file. This would have the same effect on the build as setting skip.on.failure=true. I am wondering if I should change the proposal to my original patch, which implemented fail-hard-for-everything? Yes, this will annoy continuous build admins, but that is the purpose of continuous integration: unit test failures are meant to be annoying. In my view, it is better to find more reliable network resources than to have silent unit test failures. I don't know about you, but I only read the continuous integration logs when they fail. I don't mean to sound too harsh, I am an admin and I too feel the pain. If you feel you must preserve the existing behaviour of OnlineTestCase, I am willing to implement a solution that does so. All I want is the ability to configure fixture tests to fail when something goes wrong. Your proposal meets this criterion. -- Ben Caradoc-Davies <[EMAIL PROTECTED]> Software Engineer, CSIRO Exploration and Mining Australian Resources Research Centre 26 Dick Perry Ave, Kensington WA 6151, Australia ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
