I'm not going to address the systemic problems because I think I've said more than enough about that over the years.
I do want to correct the misconception that all tests require lots of JUnit or other specific skills. There's lots of stuff that could be done by a less skilled developer or even a power user. As an example, someone who's long since left the team set up some projects which had an instance of every type of element that ArgoUML knew how to create. These are used to test project loading, upgrades (e.g. UML 1.3-> UML 1.4), basic drawing, and property panels. I upgraded them all to UML 1.4 and added a bunch of elements which had been implemented after the original author left, but I doubt every person who's implemented a new element, fig, or property panel has added the corresponding entry to the projects. Every time a new release is made, an upgraded version of these projects should get saved under a new name and, preferably, the equivalent should get recreated from scratch with the new production release. This latter step would be labor intensive if it wasn't automated, but it's not skilled labor that's required. This would allow testing of both upgraded and newly created projects. The regression suite for 0.28 could test 0.26, 0.24, and as many versions back as you wanted to go. Much of this work could even be done by a user and the test engineering work that's required is minimal. If there was a team culture that demanded quality, the implementation details would work themselves out. That's the thing to focus on. Of course it's going to require change, so you need to convince people that change isn't something to be avoided. Tom On Thu, Mar 19, 2009 at 3:58 PM, Dave Thompson <[email protected]> wrote: > Bob Tarling wrote: >> Immediate thoughts are - >> >> Not enough of junit tests. >> >> Not enough physical separation of the application into modules. >> >> A small team so not enough manual testing. >> >> Old problems with poor threading now catching up on us. >> >> Lack of resource. >> >> Lack of specific required skills. >> >> Bob. > > > I assume that your own name wasn't intended to be part of this list of > problems! > > Writing JUnit tests does not come naturally to most people, and it does > require some encouragement and often some training. For anyone who has not > done so already, I encourage them to read: > > http://junit.sourceforge.net/doc/testinfected/testing.htm > > Unfortunately, I am just as guilty, as I have not written any JUnit tests for > ArgoUML. I often think that the JUnit tests that I might dream up would be > too trivial to make a difference, and I imagine it would be difficult to > write a JUnit test to handle GUI aspects. Also, implementing a few feature > is far more rewarding that writing a test for an existing feature. Perhaps > someone could give a worked example explaining which tests are are most > useful for a given file, and where and how the tests are written, maybe in > the wiki? > > Regards, > > Dave > > ------------------------------------------------------ > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1357446 > > To unsubscribe from this discussion, e-mail: > [[email protected]]. > To be allowed to post to the list contact the mailing list moderator, email: > [[email protected]] > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1358675 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
