----- Original Message -----
From: "Thomas Calivera" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, July 15, 2001 1:47 AM
Subject: Cactus Roadmap & V2 Propsal RFC
> Vincent et al
>
> I attempted to post this earlier, but it apparently did not make the list.
> At this stage in the game, with work on V2 starting, feel free to
> respond, "Sorry, too late."
>
Just a note: you need to subscribe to cactus-user mailing list before being
to send emails to the list. Otherwise, it still works but your mail is
moderated and I have to manually accept it for it to make it to the list.
However, I have only received your email this morning.
> --
>
> Although I am one of the original proponents of combining mock testing
with
> container testing, comments by Bob Davison and others are convincing wrt
> keeping Cactus focused only on a specific type method of testing. I am
> persuaded by the argument from engineering practices to keep the
> responsibilities of a solution limited and specific. Cactus is already a
> fairly complex framework and adding additional responsibilities will
> complicate matters further. Does anyone disagree with the normative
> statement of "simple, modular testing frameworks are better than
integrated,
> complex ones?"
>
Cactus was never meant to be an in-container unit testing framework. Since
the beginning the emphasis is on server-side unit testing, whatever the
implementation. It happens that the first implementation was in-container
partly because of my lack of knowledge on mock objects. Now I think that
having a second implementation that gives a consistent solution that brings
the best to the end user is a good way to go. Mock objects tests and
in-container tests are not the same kind of tests (mock is meant to test
your logic whereas in-container is more focused on ensuring that the
relationship with the container works as expected).
I have started the implementation of v2 this week end (rewriting from
scratch) and I am 30% finished I would say (it's actually not that big). The
main goal of v2 is to have a consistent way of writing test cases, be it for
mock style, in-container style or functional style. The only complexity for
the end-user will be to choose which TestCase class to use ... There will be
several : ICWebTestCase, ICServletTestCase, ICJspTestCase for in-container
and MOServletTestCase, MOJspTestCase to use mock implementations.
The goal is not to try to tweak MO and IC so that they can be swapped at
will ... they are probably too different for it to be done simply and easily
... The goal is to provide tools for the end user.
The focus will have to be on the Methodology Guides which will explain when
to use MO and when to use IC during the development life cycle. Very
roughly, MO during development within your IDE, then once every fews hours
or once a day or rather whenever the continuous build runs, the IC tests
will also be run (along with the functional tests).
The complexity in Cactus v1 comes from the fact that the user need to
understand that there are 2 parts for the tests : the client side and the
server side. This complexity comes from in-container testing, not from
Cactus. I think we need to rewrite (or rather reorder differently) the
documentation on the web site so that it is easier to understand. What
happens is that we have been adding documentation as time goes .... Now we
should take the time to organize it into trails that will explain what to
read and in what order ...
> Another persuasive argument made by others is that the J2EE interfaces and
> contracts of those interfaces are the central reference for both mock
> objects and containers. In theory, containers run their *own* tests
against
> the specified contracts of the interfaces such that an application tested
> against well-designed mock objects will work perfectly in a container so
> tested. Otherwise, testing the containers' satisfaction of the interface
> contracts through our applications is akin to making SQL calls from JSPs -
> there is a fairly clear domain boundary violation. I partially understand
> the practical reasons to test through our applications, but can anyone
> resolve the
> theoretical conundrum?
>
er ? I could give a lot of counter examples that shows that the container
either does not behave exactly as mentionned in the spec. or rather that
there was a lack of clear specification at some point in the spec so that
the container chose a proprietary manner to implement it. Rather than giving
you sample I'd suggest you have a look at the changelogs of servlet engines
(or application servers in general) from version to version. You'll see all
the corrections that are done to comply more to the spec and all the bugs
fixed .... !
> The current proposal is certainly workable and a fine job, but, given the
> above, perhaps it is worth considering, before moving ahead too far, some
> possible alternative proposals down the path of separating Cactus into two
> projects, a Cactus-Container that runs tests *on a container itself* to
> determine its satisfaction of the implied contracts and specifications and
a
> Cactus-Mock that is used by
> application developers to test their servlets and JSPs?
>
Yes, I had thought about this. But it is a pain to maintain 2
implementations in separate projects and again that was not the goal of
Cactus (the ultimate goal of Cactus is to cover the full J2EE spectrum for
unit testing, whatever the techniques used to do so .... and of course
provided it remains usable and not too complex, which I believe we can
achieve in v2).
> Tom
Thanks a lot for sharing your view, Tom. I really appreciate it and I agree
to some extent to what you say. However, I'd like to make the experiment. If
it happens it is really too complex either to implement or use, we'll
separate the two. For the time being work is being continued on the 1.x
branch and I am also progressing on the 2.x one. I hope to deliver a v2 in
approx. a month (as I can only work during week ends, unfortunately). We'll
judge how good it is at that time and decide whether to release it or not
(I'll put it as a beta for some time).
How is that ? Tell me if you're still against it after my try to convince
you ... :-)
-Vincent
