Read over the proposal; I think this is a case were we can come to a
decision without a formal proposal since this just effects us the devel
community and the change is not visible to user code. But that is my take on
it - we are still sorting out when a proposal is useful and when it is a
waste of time :-)
I see what you are getting at; and I think we could be more specific and
still cover all out bases. I would like to disable the test when the service
in question cannot be reached (either due to firewall issues or something
like that). If we actually have a problem making the connection because of
version incompatibility or something then that is a perfectly good error to
report.
Does the difference make sense?
I think it would also be okay to have a build time property that you could
set to *ensure* the external service is contacted. -Donline=required, or
-Dstrict =true or something.
Two more ideas:
- Finally the whole OnlineTest thing is not quite applied yet; I cannot
always build GeoTools with a -o option an expect to be able to run tests. It
may be worth making a few more TestCase super classes that are not so stuck
on this "connection" idea ...
- JUnit4 annotations; I wonder if we can just do this stuff for a single
method @OnlineTest ? It could check the environmental variable to see if -o
is being used; and if so skip that particular method?
Cheers,
Jody
On Wed, Feb 4, 2009 at 11:52 AM, Ben Caradoc-Davies
<ben.caradoc-dav...@csiro.au> wrote:
> Andrea Aime wrote:
> > Ben Caradoc-Davies ha scritto:
> >> I propose that an optional key be added to OnlineTestCase to cause test
> >> failure on failed connection:
> >>
> http://docs.codehaus.org/display/GEOTOOLS/OnlineTestCase+support+for+failure+on+failed+connection
> >
> > Works for me. Just a minor note, there is one other case in which you
> > don't want online test to fail on run, and that is, when the
> > online resource you're looking for is not really there, and will
> > never be.
> > Just think of all the jdbc datastores we have. We don't have
> > test databases available online for testing, and even if
> > we had, it would be so slow to make it un-practical to
> > run 130+ tests against them.
> > Personally I have many of the databases we support, but not
> > DB2 with spatial extensions, yet I don't want to take
> > db2 module out of the build for that reason (I still want
> > to check it compiles).
> > Anyways, the proposal is ok, just wanted to point out another
> > good reason for having the current default behaviour ;)
>
> I agree wholeheartedly. The per-user fixture configuration is in my view
> the most useful feature of OnlineTestCase. It is an implicit goal of the
> proposal that the fixture configuration behaviour be preserved; only the
> option to fail on connect()/disconnect() failure is added.
>
> Kind regards,
>
> --
> Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au>
> Software Engineer, CSIRO Exploration and Mining
> Australian Resources Research Centre
> 26 Dick Perry Ave, Kensington WA 6151, Australia
>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code
> to
> build responsive, highly engaging applications that combine the power of
> local
> resources and data with the reach of the web. Download the Adobe AIR SDK
> and
> Ajax docs to start building applications today-
> http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
