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