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" <[EMAIL PROTECTED]> To: "Cactus Developers List" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]] > Sent: Wednesday, November 28, 2001 1:57 AM > To: Cactus Developers List > Subject: Re: [proposal] Cactus v2 > > > > > ----- Original Message ----- > From: "Kaarle Kaila" <[EMAIL PROTECTED]> > To: "Cactus Developers List" <[EMAIL PROTECTED]> > 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:[EMAIL PROTECTED] > > tel: +358 50 3725844 > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
