On 16 Aug 2002, Cliff Rowley wrote:
> Date: 16 Aug 2002 22:00:32 +0100
> From: Cliff Rowley <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: XP (and not the Microsoft kind)
>
> On Fri, 2002-08-16 at 21:19, Craig R. McClanahan wrote:
> > I've used similar pieces of XP's philosophy as well - especially the
> > daily integration stuff. (One example is Sun's JWSDP, where I was the
> > implementation architect - one of the things we did was build the entire
> > thing from source every night, which helped flush out a lot of potential
> > incompatibilities; sort of like what Gump does for open source projects
> > <http://jakarta.apache.org/gump/>).
>
> I've seen it cropping up more and more. The Eclipse project is all unit
> test based isn't it? You can flit through the releases looking at the
> unit test results.
>
I don't know about Eclipse, but back in Jakarta land the new Maven project
management package (http://jakarta.apache.org/turbine/maven/) has some
built in capabilities for managing unit tests, along with everything else
it does. I'm going to want to consider this for Struts's basic build
process -- post 1.1 of course.
> > Personally, I've never been comfortable with pair programming, but that's
> > probably more a personal quirk than any statement about the value of the
> > concept.
>
> I was a bit like that at first, but now I have thought about it I can
> see that really my problem is really just mindset. It's not something
> I've tried before, but I'll give anything a go once.
>
Part of my problem is that the nature of open source development has been
much more "loners communicating via CVS commits" and I grew pretty
comfortable with that :-).
> > One XP principle that is starting to become pervasive in Jakarta projects
> > is unit tests, including the notion that building tests is part of
> > building the code, you're not done until you've got unit tests to prove
> > that it works, and the idea of adding unit tests every time you fix a bug
> > to catch regressions. Struts itself is woefully behind the curve on this
> > (something I want to address after 1.1), but you'll see pretty
> > comprehensive JUnit based unit test suites in the source code of all the
> > Commons packages -- "ant test" is the usual way to invoke them.
>
> I'm sure I've seen a unit test package for Struts somewhere. It may
> have been on freshmeat.net if it's not something the Struts team have
> been working on (I mean that I may have seen it somewhere in the Jakarta
> website).
>
There is in fact a set of unit tests in the Struts code base -- the
"test.junit" target in the top-level build script runs the JUnit based
ones, while "ant test.tomcat.xx" runs Cactus-based tests on various
versions of Tomcat. The current coverage of these tests, versus all the
code in the framework, is pretty small :-(.
For unit testing web apps based on Struts, check out the Cactus framework
<http://jakarta.apache.org/cactus/>. One of Vincent's initial motivations
was in fact to support just this use case, but he sensibly broadened it to
in-container testing of any servlet/jsp based webapp. The discussions of
using "mock object" tests versus "in container" tests is also very
illuminating.
> > I've gone from a "unit tests are nice" attitude to a "unit tests are
> > vital" attitude based on my own experience with them.
>
> Although my experience is limited, I can very much see the benefits.
> Reading about the roots of XP, looking over past experiences and
> learning lessons prompted me to think about the way I develop software.
> It's not been easy, and until now I have pretty much left it in the
> hands of the people I have been working for at the time to lead the way
> (also partly a confidence thing, if I knew what I was doing I wouldn't
> be such a pushover). I've never got on well with the 'traditional'
> methods that have been forced down my throat either - I never went to
> university, and I did no IT at school. Everyone appears to do things
> differently, and most of the time the whole process feels unnatural and
> I feel uncomfortable with it. I've left two companies in my short
> history simply because I couldn't stand the way things were being done.
> Suicidal as that sounds in a forever fluctuating job market, for some
> reason I cannot let it go. Java is about the 9th programming language
> I've learned, and the one I have decided to stick to - it says 'all the
> right things' to me, and prior to that, *NIX 'said all the right things'
> to me - and now I use them almost exclusively. But despite that I have
> always had the nagging problem that I am not enjoying the tools because
> the development processes are too abrasive and they take the fun out of
> the work. If nothing else, XP appears to be a way to re-inject that.
> --
>
The thing I like best about unit tests is that it reduces the risk of
changes to class "foo" (made by you or by others on the team) causing
failures in class "bar" that don't show up until your customer calls in a
problem report. It gives you the freedom to make changes quickly and
continuously, with instant feedback on breakage, which ties right in to
the XP philosophical approach. Of course, this all depends on the
coverage percentage of your test suite ...
> Regards
>
> -------------------------------------------
> Cliff Rowley | [EMAIL PROTECTED]
> Software Engineer | www.doctype.co.uk
> +44 (0) 1206 514263 | www.cliffrowley.com
> -------------------------------------------
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
