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