RE: Erik Hatcher's Struts Test case

[Nicholas Lesiecki <ni...@eblox.com>]

What do we think about including Erik hatcher's submission in Cactus
1.3--perhaps in an optional download, or in a package such as
org.apache.cactus.extensions? I looked over the class, and it seemed pretty
clean. Certainly a lot of Cactus users are Struts users and vice versa.

Opinions?

cheers,

nick
-----Original Message-----
From: Vincent Massol [mailto:vmassol@octo.com]
Sent: Wednesday, November 28, 2001 1:57 AM
To: Cactus Developers List
Subject: Re: [proposal] Cactus v2




----- Original Message -----
From: "Kaarle Kaila" <ka...@iki.fi>
To: "Cactus Developers List" <ca...@jakarta.apache.org>
Sent: Tuesday, November 27, 2001 9:10 PM
Subject: Re: [proposal] Cactus v2


> hi!
>
> I don't know if I should have an opinion on this matter as there is so
much
> in it that
> I don't know about. Also I have not had time to look at aspctj further.
> So take my ignorance in account with my comments.
>
> I heard first time of JUnit last summer and was fascinated by the ideas in
it.
> JUnit is straight forward and using JUnitEE and/or Cactus makes it
possible
> to test also J2EE components.
>
> Now you propose, that Cactus would no longer be JUnit testcases but
> something else. You would also like to include checking the code against
> rather abstract design patterns - sounds complicated and hard to
understand
> or implement.
>
> If the tests become very complicated will anybody use them?
> Remember, that the main interest for the programmer is to
> write his program, if testcases can be implemented easily
> and the programmer has real use of them e.g. as he can
> write the testcases instead of  auxiliary main-programs
> while he writes the components.

I fully agree with you and I can assure you that the easyness to write tests
has always been on my mind. Maybe I should have better explained why I feel
the need to change the existing Cactus :
* Cactus is far is meant to be a full unit testing framework for server side
components but only really addresses the area of integration testing (from
beginning to end).
* Whenever I write a J2EE application, I personally always feel the need to
write mock object like tests that executes quickly and that do not test the
environment. Then, once you have this, the urge to write integration tests
is less strong as you can get away by simply performing the functional
tests. In any case, you have to write several tests against several
frameworks.
* Cactus has limitations in the integration area and not test 100% as if it
were in real. It is missing an interception mechanism where you would
intercept the real request on the real component (instead of using a
redirector and passing its context) for integration tests.
* Cactus could be simpler to use/install (this is what I propose with
aspectj).

Bear in mind that this is a proposal and we will need a proof of concept
before deciding to continue in this direction. Also, Cactus v1 is not going
to be dropped, it will remain for the forseeable future.

WRT to junit, you may have noticed that cactus tests are not exactly unit
tests (it adds beginxxx, endxxx, setup and teardown are exectued on the
server side, ...). So we're already not using junit as is ... JUnit is not
designed to accept very well extensions (there are talks on several mailing
list to improve it in the future but nothing has been decided).

I think writing a test with aspectj is quite easy and expresses better what
the unit test is about. With aspects, you're actually saying : catch the
call to this method and instead of returning this value, return this fake
one for my test. It is expressed in 2 lines of code and is very expressive.
Using mock objects, you're saying the same thing but with traditional java
so it is more convoluted : you have to find a way to pass your mock in. Thus
2 drawbacks : 1/ you have to write the mocks or have mocks ready and 2/ your
program need to be really well designed before you can test it. The second
point is an advantage but on all projects I have seen, the projects were
never well designed this way and it was almost impossible to test anything
with refactoring the whole project.

In the near future, I'll post an example of test case written with Cactus v1
and with Cactus v2 to show the difference. I'll also post other test case
that show how to do things that are not even imaginable with any other
testing frameworks ! :)

Thanks for your participation.
-Vincent

>
> OK! I have been wrong sometimes. Especially when trying to
> forecast into the future. This could of course be such time?
>
> regards
> Kaarle Kaila
>
>
> >It means that a single test is no longer made up of a single testXXX()
> >method as in junit but can actually be composed of as many "checkpoints"
as
> >is desirable (and needed).
> >
> >Note that all this will mean that cactus v2 tests will not be junit test
> >cases. However, it is probably possible to write a wrapper facade (if we
> >wish) so that junit test runners could be used along with existing junit
> >integration tools in IDEs for example.
> >
> >What do you think about all that ? Im' interested in your feedback !
> >Thanks
> >
> >-Vincent
>
> ---------------------------------------------
> Kaarle Kaila
> http://www.iki.fi/kaila
> mailto:kaarle.kaila@iki.fi
> tel: +358 50 3725844
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Erik Hatcher's Struts Test case

[Vincent Massol <vm...@octo.com>]

I'm ok for the extension package. But on the condition that someone
volunteer for that :). We will also have to maintain it as Struts evolves.

-Vincent

----- Original Message -----
From: "Nicholas Lesiecki" <ni...@eblox.com>
To: "Cactus Developers List" <ca...@jakarta.apache.org>
Sent: Wednesday, November 28, 2001 3:51 PM
Subject: RE: Erik Hatcher's Struts Test case


> What do we think about including Erik hatcher's submission in Cactus
> 1.3--perhaps in an optional download, or in a package such as
> org.apache.cactus.extensions? I looked over the class, and it seemed
pretty
> clean. Certainly a lot of Cactus users are Struts users and vice versa.
>
> Opinions?
>
> cheers,
>
> nick
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@octo.com]
> Sent: Wednesday, November 28, 2001 1:57 AM
> To: Cactus Developers List
> Subject: Re: [proposal] Cactus v2
>
>
>
>
> ----- Original Message -----
> From: "Kaarle Kaila" <ka...@iki.fi>
> To: "Cactus Developers List" <ca...@jakarta.apache.org>
> Sent: Tuesday, November 27, 2001 9:10 PM
> Subject: Re: [proposal] Cactus v2
>
>
> > hi!
> >
> > I don't know if I should have an opinion on this matter as there is so
> much
> > in it that
> > I don't know about. Also I have not had time to look at aspctj further.
> > So take my ignorance in account with my comments.
> >
> > I heard first time of JUnit last summer and was fascinated by the ideas
in
> it.
> > JUnit is straight forward and using JUnitEE and/or Cactus makes it
> possible
> > to test also J2EE components.
> >
> > Now you propose, that Cactus would no longer be JUnit testcases but
> > something else. You would also like to include checking the code against
> > rather abstract design patterns - sounds complicated and hard to
> understand
> > or implement.
> >
> > If the tests become very complicated will anybody use them?
> > Remember, that the main interest for the programmer is to
> > write his program, if testcases can be implemented easily
> > and the programmer has real use of them e.g. as he can
> > write the testcases instead of  auxiliary main-programs
> > while he writes the components.
>
> I fully agree with you and I can assure you that the easyness to write
tests
> has always been on my mind. Maybe I should have better explained why I
feel
> the need to change the existing Cactus :
> * Cactus is far is meant to be a full unit testing framework for server
side
> components but only really addresses the area of integration testing (from
> beginning to end).
> * Whenever I write a J2EE application, I personally always feel the need
to
> write mock object like tests that executes quickly and that do not test
the
> environment. Then, once you have this, the urge to write integration tests
> is less strong as you can get away by simply performing the functional
> tests. In any case, you have to write several tests against several
> frameworks.
> * Cactus has limitations in the integration area and not test 100% as if
it
> were in real. It is missing an interception mechanism where you would
> intercept the real request on the real component (instead of using a
> redirector and passing its context) for integration tests.
> * Cactus could be simpler to use/install (this is what I propose with
> aspectj).
>
> Bear in mind that this is a proposal and we will need a proof of concept
> before deciding to continue in this direction. Also, Cactus v1 is not
going
> to be dropped, it will remain for the forseeable future.
>
> WRT to junit, you may have noticed that cactus tests are not exactly unit
> tests (it adds beginxxx, endxxx, setup and teardown are exectued on the
> server side, ...). So we're already not using junit as is ... JUnit is not
> designed to accept very well extensions (there are talks on several
mailing
> list to improve it in the future but nothing has been decided).
>
> I think writing a test with aspectj is quite easy and expresses better
what
> the unit test is about. With aspects, you're actually saying : catch the
> call to this method and instead of returning this value, return this fake
> one for my test. It is expressed in 2 lines of code and is very
expressive.
> Using mock objects, you're saying the same thing but with traditional java
> so it is more convoluted : you have to find a way to pass your mock in.
Thus
> 2 drawbacks : 1/ you have to write the mocks or have mocks ready and 2/
your
> program need to be really well designed before you can test it. The second
> point is an advantage but on all projects I have seen, the projects were
> never well designed this way and it was almost impossible to test anything
> with refactoring the whole project.
>
> In the near future, I'll post an example of test case written with Cactus
v1
> and with Cactus v2 to show the difference. I'll also post other test case
> that show how to do things that are not even imaginable with any other
> testing frameworks ! :)
>
> Thanks for your participation.
> -Vincent
>
> >
> > OK! I have been wrong sometimes. Especially when trying to
> > forecast into the future. This could of course be such time?
> >
> > regards
> > Kaarle Kaila
> >
> >
> > >It means that a single test is no longer made up of a single testXXX()
> > >method as in junit but can actually be composed of as many
"checkpoints"
> as
> > >is desirable (and needed).
> > >
> > >Note that all this will mean that cactus v2 tests will not be junit
test
> > >cases. However, it is probably possible to write a wrapper facade (if
we
> > >wish) so that junit test runners could be used along with existing
junit
> > >integration tools in IDEs for example.
> > >
> > >What do you think about all that ? Im' interested in your feedback !
> > >Thanks
> > >
> > >-Vincent
> >
> > ---------------------------------------------
> > Kaarle Kaila
> > http://www.iki.fi/kaila
> > mailto:kaarle.kaila@iki.fi
> > tel: +358 50 3725844
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>