cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Leicester <>
Subject JUnit tests and packages
Date Sun, 03 Aug 2003 22:29:26 GMT

I am writing some Cocoon components to deal with MIDI file (generator and
serializer), that I would like to make available at some stage if they are
wanted. In my normal course of development I create JUnit tests (ok, I admit
this is a recent 'normal'; I've only recently seen the light). Where should
I put my test classes? For example, I am creating an
o.a.c.generation.MIDIGenerator, at moment. I have put my TestMIDIGenerator
class into o.a.c.test.generation. Is that sensible? Do you have any other
preferred suggestions? I see that the Chaperon block includes some unit
tests, but otherwise they are not widely implemented. Is the widespread use
of JUnit tests desirable? If so, in due course I'd like create unit tests
for other Cocoon components too.

I've been lurking on the lists for a long time. I introduced Cocoon 2.0 into
my company's development team back in 2001. Now, regrettably, the consensus
reached in my company with respect to web application frameworks is that the
Struts approach is simpler and more robust. Rather than it having been a
Cocoon vs. Struts argument, this decision had more to do with many of our
developers' preferences for Java data structures over XML, e.g. "too many
layers = bad performance", "XML makes coding unnecessarily complex" etc. As
you may have experienced in your own working lives, these sorts of arguments
can cripple progress in a small team environment so I have reluctantly ceded
Cocoon and XML from the core of our information strategy.

On the plus side this means that now I realise that the best way to continue
to work with Cocoon, which I love dearly and see a great future for, is to
contribute directly to the main Cocoon development effort. I hope I can


View raw message