+0 on graduation, with the lack of unit test coverage being the main problem. The "+" comes from the two unit tests running while not headless. Note that, because these tests exit early when headless, we have 0% test coverage on Hudson, where we use -Djava.awt.headless=true.
Swing is a pain to test. MVC is problematic, but Swing seems to cause serious problems. I like the Passive View pattern as a way of improving testability: http://martinfowler.com/eaaDev/PassiveScreen.html If your view contains all the Swing UI, you can even retain unit test coverage while headless and test the model and controller. Kind regards, Ben On 29/09/09 08:01, Jody Garnett wrote: > Hi Christian. > > When we proposed this module (as a replacement for gt-widgets-swing) > the idea was to take it offline to unsupported for a few months and > put back only what we ended up using. My understanding was that were > were going to focus on examples rather then test coverage and we have > spent out time accordingly. > > Christian could I ask you to help set up a swing test framework; I > have no recent experience in this area. > > Jody > > On 29/09/2009, at 2:43 AM, Christian Müller wrote: > >> I am with Andrea concerning the test coverage. >> I am always trying hard to get a good code coverage, investing >> sometimes more time in creating the the test cases than in the >> module itself. >> Additionally, since I developed a Swing applet for showing maps and >> modifying geometries, I know Swing is a nasty thing. We had problems >> supporting both sun java 5 and sun java 6. I did not go further and >> check with ibm sdks or openjdk and made sun java 6 a prerequisite, >> over and out. This was only possible because the applet is a special >> application dedicated for about 100 users. >> From my point of view, there are 2 things I worry about. >> 1) As Andrea stated, 4% coverage is quite poor >> 2) I am afraid, thinking on the build servers I want to deploy, that >> there will be problems with IBM Hudson and OpenJDK Hudson. >> My proposal would be >> a) Integrate a Swing test framework into geotools >> b) Increase the code coverage >> c) check with different sdks, otherwise we have a time bomb here. >> The idea about the module is ok, a good starting point for developing. >> > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineer, CSIRO Earth Science and Resource Engineering Australian Resources Research Centre 26 Dick Perry Ave, Kensington WA 6151, Australia ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
