Ben Caradoc-Davies wrote: > Jody Garnett wrote: >> 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 :-) > > Jody, Jody, I am hyperventilating. There is a heat wave on - calm. > http://n2.nabble.com/Prevent-silent-failures-of-online-tests-tp1954287p1954294.html > > > "That works for me; but remember you will need to make a formal proposal > on this one (since we are trying to change the build policies)." - > Jody Garnett, 2008-08-18 Hrm you are right; Justin wanted proposals for things that effect the build. I think he was mostly focused on maven; but broad changes to the entire test process would qualify. I think you are just asking the super class to support a new option which you are going to make use of in your module however?
>> 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? > Yes, but how do you tell? OnlineTestCase would need to know all > exception types that might be thrown by future implementations on > connection failure. Some may be RuntimeException. How do we tell if > this is a transient connection failure? And what if the implementation > is incorrect and throws a could-not-contact exception when it is broken? You are correct; we may not be able to provide one magic OnlineTestCase class to make everyone happy here. The door is open to make additional classes to help others; you can define them in your module and make sure you are happy with them; and when someone in another module wants similar functionality we can "pull it up" into the testing support module. > These are only tests, and do not have to be feature-complete. I just > want them to fail when something goes wrong. That is why they are there. Understood; we also need to make sure the tests do not run for someone who is offline; or who cannot connect to your server due to firewall issues. >> 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. > I think Andrea's earlier comment reminds us that one person's remote > service is another person's local service , so per-fixture > configuration is useful. Right; so you want to add something to your fixture that will ask it to "fail" if a connection is not made. That sounds much better than hardcoding it into the choice of super class... Jody ------------------------------------------------------------------------------ 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
