You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Mark Leicester <ma...@metering.co.nz> on 2003/08/04 00:29:26 UTC

JUnit tests and packages

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


[OT] Cocoon's jukebox (Re: JUnit tests and packages)

Posted by Marc Portier <mp...@outerthought.org>.
Sylvain Wallez wrote:

<snip />

> side that makes Cocoon like no other software: are there other 
> frameworks on earth that can both connect to SAP and produce MIDI files 
> at the same time ?
> 
> Sylvain (waiting to listen to Cocoon music ;-)
> 


Yo piano-man, play me that SAP-tune again, and throw in some 
SAXophone :-)

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org


Re: JUnit tests and packages

Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:

> Mark Leicester wrote:
>
>> 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.
>
>
> Sure they're wanted, as long as you're willing to donate them ! 


Ditto :)


>> I have put my TestMIDIGenerator class into o.a.c.test.generation. Is 
>> that sensible? Do you have any other preferred suggestions?
>

This could be easily refactored, don't worry about this.


>> Is the widespread use of JUnit tests desirable?
>

YES!!!

<snip/>

>> 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!
>
>
> Every contribution is welcome, and yours is definitely on the creative 
> side that makes Cocoon like no other software: are there other 
> frameworks on earth that can both connect to SAP and produce MIDI 
> files at the same time ?


I'd like to see this as well :)

Vadim



Re: JUnit tests and packages

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Mark Leicester wrote:

>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.
>

Sure they're wanted, as long as you're willing to donate them !

>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.
>

JUnit tests are more than desirable, and if we don't have much of them, 
it's because we're lazy butts. So if you want to contribute some, this 
is a very welcomed effort.

>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.
>

Sad, but well-known story... The advent of flowscript and Woody will 
leave little room for Struts, feature-wise. Now that's true that Cocoon 
is a big beast that takes long to master. Only after this one can see 
the incredible benefits in brings.

>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!
>

Every contribution is welcome, and yours is definitely on the creative 
side that makes Cocoon like no other software: are there other 
frameworks on earth that can both connect to SAP and produce MIDI files 
at the same time ?

Sylvain (waiting to listen to Cocoon music ;-)

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Re: JUnit tests and packages

Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Lundi, 4 aoû 2003, à 00:29 Europe/Zurich, Mark Leicester a écrit :

> ...I am writing some Cocoon components to deal with MIDI file 
> (generator and
> serializer...


Cool!
I haven't done MIDI for a while but started a looong time ago (1983, by 
designing an accordion-to-MIDI interface) so you can count me in the 
fan club ;-)

If you can package your components as a block with samples, including 
them in Cocoon shouldn't be a problem.

> ...Is the widespread use
> of JUnit tests desirable?...

Certainly - currently there are only a small number of them but more 
won't hurt.

-Bertrand