Q: testing (hopefully test-driving development) with Cocoon

[Wojciech Biela <il...@gmail.com>]

Hi

I may be wrong, I haven't been around for some time in Cocoon land so
if I'm just talking crazy don't hasitate to tell me that.

As the subject states I have a question to the *active* users and
developers of Cocoon about their development and testing practices.

1. Do you unit test all your Cocoon java code?
2. If so, do you use TDD as your development method? If not, why?
3. If you use TDD, how do you test-drive all the logic present in
flowscripts, because that's the thing that worries me most. I love the
idea, but it's awfully easy to introduce bugs (that Java would pick up
at compile-time) and most disturbing I dunno any way to unit test such
parts of application. Huh?

Maybe there is some way that I just don't know yet, if there is tell
me please, if there isn't then I suggest we start looking for one,
because I don't know what about the others but everyone I know
including me who tried full blown TDD don't want to go back to
code&fix, and certainly I don't want to give up Cocoon because of it
not being a suitable framework for TDD.

-- Wojtek Biela

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: Q: testing (hopefully test-driving development) with Cocoon

[Bertrand Delacretaz <bd...@apache.org>]

Le 16 mai 05, à 11:23, Wojciech Biela a écrit :
>> ...For unit testing flowscript, I'd use an HTTP-based method, which 
>> allows
>> you to test the full request processing chain "in situ".
>
> the problem in that is that it's not real unit testing, unit testing
> should be done *in isolation*, this HTTP based testing is closer to
> integration testing or functional testing..

I see what you mean, but if you test a flowscript from HTTP/XML, 
testing the output of the JXTemplateGenerator for example, before any 
transforms, you're fairly close to unit testing. And the tools to do 
this are readily available. But of course there might be space for more 
isolated tests.

>> ...To test my custom Cocoon components in their environment, I've been
>> using a custom JUnitGenerator...

> I suppose that this approach lacks isolation as well, anyway I'll be
> happy to take a look at it if you could publish the code somewhere

ok, I'll try to find some time to do this.

-Bertrand

Re: Q: testing (hopefully test-driving development) with Cocoon

[Wojciech Biela <il...@gmail.com>]

> Yes, javascript-based flow is the recommended way, javaflow is stil
> "officially" considered experimental (but AFAIK very usable and stable
> already).

huh, alright, anyone cares to post some pros & cons of those two flow
languages (javascript flow vs javaflow)?

> For unit testing flowscript, I'd use an HTTP-based method, which allows
> you to test the full request processing chain "in situ".

the problem in that is that it's not real unit testing, unit testing
should be done *in isolation*, this HTTP based testing is closer to
integration testing or functional testing, that is also cool but it
doesn't give the scope useful for test-driven development.

> You're right that unit testing flowscript directly could be useful, but
> I don't think we have examples of doing it in Cocoon currently. If
> you'd like to try and create something for this, there are several
> examples of JUnit testing of Cocoon components in the codebase, which
> should be a good base to start from.

I'll research that possibility
 
> To test my custom Cocoon components in their environment, I've been
> using a custom JUnitGenerator, which executes JUnit tests in the same
> environment than my production components (database configs etc) and
> outputs the results in XML. I forgot to mention this when we talked
> last week after your comment on my weblog.

I suppose that this approach lacks isolation as well, anyway I'll be
happy to take a look at it if you could publish the code somewhere

> It's fairly rough and probably not general, but if you'd like to
> improve it I could post the code on the wiki as an example. I don't
> think it would help much about flowscript testing but it could give you
> some ideas.

I'll could give it a try

-- Wojtek Biela

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: Q: testing (hopefully test-driving development) with Cocoon

[Bertrand Delacretaz <bd...@apache.org>]

Le 16 mai 05, à 10:34, Wojciech Biela a écrit :

> On 5/12/05, Ralph Goers <Ra...@dslextreme.com> wrote:
>> Did you know you can write your flow in Java?
>
> yes I heared of it, but I see the mainstream for flow in Cocoon is
> JavaScript so I assume for some reason it's preffered to use it (but
> then problem is unit testing arise), am I wrong?

Yes, javascript-based flow is the recommended way, javaflow is stil 
"officially" considered experimental (but AFAIK very usable and stable 
already).

For unit testing flowscript, I'd use an HTTP-based method, which allows 
you to test the full request processing chain "in situ".

You're right that unit testing flowscript directly could be useful, but 
I don't think we have examples of doing it in Cocoon currently. If 
you'd like to try and create something for this, there are several 
examples of JUnit testing of Cocoon components in the codebase, which 
should be a good base to start from.

To test my custom Cocoon components in their environment, I've been 
using a custom JUnitGenerator, which executes JUnit tests in the same 
environment than my production components (database configs etc) and 
outputs the results in XML. I forgot to mention this when we talked 
last week after your comment on my weblog.

It's fairly rough and probably not general, but if you'd like to 
improve it I could post the code on the wiki as an example. I don't 
think it would help much about flowscript testing but it could give you 
some ideas.

-Bertrand

Re: Q: testing (hopefully test-driving development) with Cocoon

[Wojciech Biela <il...@gmail.com>]

On 5/12/05, Ralph Goers <Ra...@dslextreme.com> wrote:
> Did you know you can write your flow in Java?

yes I heared of it, but I see the mainstream for flow in Cocoon is
JavaScript so I assume for some reason it's preffered to use it (but
then problem is unit testing arise), am I wrong?

-- Wojtek Biela

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: Q: testing (hopefully test-driving development) with Cocoon

[Ralph Goers <Ra...@dslextreme.com>]

Did you know you can write your flow in Java?

Ralph

Wojciech Biela wrote:

>Hi
>
>I may be wrong, I haven't been around for some time in Cocoon land so
>if I'm just talking crazy don't hasitate to tell me that.
>
>As the subject states I have a question to the *active* users and
>developers of Cocoon about their development and testing practices.
>
>1. Do you unit test all your Cocoon java code?
>2. If so, do you use TDD as your development method? If not, why?
>3. If you use TDD, how do you test-drive all the logic present in
>flowscripts, because that's the thing that worries me most. I love the
>idea, but it's awfully easy to introduce bugs (that Java would pick up
>at compile-time) and most disturbing I dunno any way to unit test such
>parts of application. Huh?
>
>Maybe there is some way that I just don't know yet, if there is tell
>me please, if there isn't then I suggest we start looking for one,
>because I don't know what about the others but everyone I know
>including me who tried full blown TDD don't want to go back to
>code&fix, and certainly I don't want to give up Cocoon because of it
>not being a suitable framework for TDD.
>
>-- Wojtek Biela
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org