Ben Caradoc-Davies wrote: > That sounds good. I wrote a long rebuttal and then realised I agreed > with you. :-) > > How about (apologies for the ASCII-UML): > > TestCase <|-- FixtureTestCase <|-- OnlineTestCase > > That is, we introduce FixtureTestCase as an intermediate extension > point between TestCase and OnlineTestCase, and pull up all the fixture > handling into FixtureTestCase. If you are happy that all > OnlineTestCases are types of fixtures, we can have the > exception-swallowing added in OnlineTestCase only. Users of > OnlineTestCase are none-the-wiser, new tests can choose to fail on bad > connect() [by extending FixtureTestCase], and everyone is happy. The > manual can be updated to reflect the new class as an option. > > How does this sound? > > I'll implement it, and if it works for me, I'll propose it. 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). The two areas people often forget about when doing this sort of thing are 1) "tasks" - designed to make sure there are enough bodies around to do the work. 2) documentation - in this case updating the developers guide
Cheers, Jody ------------------------------------------------------------------------- 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
