Hello, 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 help! Regards, Mark
