----- Original Message -----
From: "Nicholas Lesiecki" <[EMAIL PROTECTED]>
To: "Cactus Developers List" <[EMAIL PROTECTED]>; "Vincent
Massol" <[EMAIL PROTECTED]>
Sent: Wednesday, November 28, 2001 3:48 PM
Subject: RE: [proposal] Cactus v2
> Hello,
>
> I think the proposed redesign of Cactus sounds like a great idea. I'm not
> sure it will work out, or work out exactly as Vincent has outlined, but
> that's what OS is all about--experimentation and cool stuff.
>
Exactly. So far, it is only a proposal. We'll then need to make a prototype
to validate it can be done and works. Then only it could be chosen as the
replacement of Cactus if everyone agrees.
> JUnit is in fact a very simple framework, and I think that we should
strive
> to keep the results of this Cactus refactoring as simple to use as the
> original JUnit was. That being said, I think AspectJ might actually help
us
> considerably.
Yes, we should strive for that. However, what we are doing is much more
powerful that what Junit can do (not much in the server side domain). So
even if it is slighlty harder to use than junit, the advantages might still
balance the additional effort.
>
> Consider this problem from many places in my Code:
>
> SomeEJB ejb = lookUpFromJndiSomehow();
> if (ejb.updateSomeRecord()){
> forwardTo("index.page");
> }
> else{
> forwardTo("error.page");
> }
>
> Now suppose I want to test the class that this method hides in. With
> traditional testing methods, I have difficult time overriding the
> lookUpFromJndiSomehow() method so that I can pass in a mocked ejb. (one
> where I can simply return true from updateSomeRecord()) Jndi lookups are
the
> easiest and quickest way to get and EJB, and also allow for significant
> flexibility. But without hijacking the JNDI mechanism somehow (either
> changing my deployment descriptor for tests or putting stuff in JNDI in my
> IDE) I can't replace the ejb I get back! Using aspects to test this class,
I
> could easily swap in a mocked EJB.
>
> There are a couple problems I see with this approach.
>
> 1. the tests may depend upon internal implementation details. (as here, if
I
> get the ejb from somewhere other than JNDI, the test will no longer
> compile.) However, this is not terrible, as Vincent is correct, most
systems
> are in a state of decay and would need significant refactoring before
their
> design was such that they had (traditionally) testable units. While I love
> refactoring, the fact of the matter is, if every writing a test for a
small
> new class involved scrapping your company's persistence architecture, most
> developers (even me!) will skip the test as being too hard.
I don't understand you point here. The tests we are referring to are white
box test, and you need to know the implementation to write them. ... oh I
see what you mean : you're saying that ideally one should provide an
interface that hides the implementation details. Yes, this is the only
reason why I like the mock object approach but this is very much doable with
cactus v2. It's just that it won't enforce it by forcing users to code in a
nice way. But that has been the wide-spreading adoption of mock objects so
far (my opinion here).
We'll certainly need a good methodology guide with several best practice
examples.
>
> Traditional testing methods for getting around this problem that do not
> involve refactoring are equally complex and less than pure.
>
> 2. Would the code need to be recompiled with for the tests to run? This is
a
> small disadvantage, and smaller than I originally suspected, since the
> Aspect would only work its magic if the join point was identified within
the
> test runner (i.e. have no effect outside the runner...).
yep.
thanks
>
> Anyway, those are my thought for now.
>
> 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]>
