----- Original Message -----
From: "Thomas Calivera" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, July 15, 2001 4:09 PM
Subject: Re: Cactus Roadmap & V2 Propsal RFC
> Vincent
>
> Thank you for your response. The purpose of my email is not, necessarily,
to
> ask for a change in the V2 proposal, but to raise some issues and
potential
> alternatives to keep in mind as the versions march onward. The V2 proposal
> provides a common reference point.
>
Good. Although I have done a poor job of describing in detail what I have in
mind for V2 ... However, it is something that evolves while thinking about
it ... It is still very early in the thought process and I discover new
ideas/ways of doing it every day ... However I prefer to discuss them on the
mailing list as they come to get the feedback from all of you. So I'll try
to explain better below what I've come up with today .... ! :)
> "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."
>
> Unless I missed something, this is not clear from the proposal or roadmap.
> Until now, I assumed that you extended a common test case class for both
IC
> and MO and then switched from mock to container(s) testing depending on
> configuration.
>
You're right is wasn't mentionned. My initial goal was to have for example a
single ServletTestCase class that could be used for both MO and IC. Thinking
about it, I have found 2 things :
- it is probably not crucial to have this feature as IC and MO tests can be
roughly partitioned as follows : MO to test code logic and IC to test
container interactions
- it is quite difficult to be able to switch back and forth between both. I
would prefer that we implement it the simple way first and at the same time
learn more on mock objects in cactus and then maybe in a second step we
could think of inventing a way to switch back and forth. I would prefer to
concentrate on what I think is missing the most for making cactus a full
server-side unit testing framework (and that is MO in my opinion). Again the
goal of Cactus was/is _not_ to be an IC implementation (it just happened
that I chose IC as the first implementation partly for lack of knowledge on
MO).
Now I am interested by your thoughts on this.
> "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)."
>
> If I understand the earlier breakdown of test case classes correctly, this
> means that there are two separate classes to maintain, the in-container
and
> the mock. Unless the methodology involves only mock testing internal
methods
> having little to do with the J2EE interfaces inside a servlet (which
brings
> up another question of why they are there in the first place and not in a
> bean), then you have a lot of duplication of effort going on and the
> distinct possibility that the mock and in-container tests will end up out
of
> synch.
>
Yes, you are right about the 2 sets of classes (IC and MO tests). You can
also possibly add others : integration testing, functional testing, system
testing, ... I wish I could bring the 2 together but as I said above it is
quite difficult and Id prefer to defer that task until we know better on MO
inside Cactus. Unless someone has a very nice idea to propose.
> "I think we need to rewrite (or rather reorder differently) the
> documentation on the web site so that it is easier to understand... Now we
> should take the time to organize it into trails that will explain what to
> read and in what order ..."
>
> Excellent. I saw a lot of tutorial planning on the roadmap, which is
great.
> I think a good (and completely arbitrary) benchmark for tutorial success
is
> if an intermediate programmer is up and running in 15 minutes from
download.
>
yep.
> "I could give a lot of counter examples that shows that the container
> either does not behave exactly as mentionned in the spec. "
>
> Which is why I understand the practical reasons for in-container testing.
> However, that you have as much evidence for this practical side indicates
> that the server offerings claiming J2EE compliance are in pretty sad
shape.
It is not always their fault. A spec always left things unspecified.
Otherwise it would have to be defined at the "bit level", which wouldn't
leave much space for improvements (like the TCP/IP spec for instance).
> I think this lends support to the concept of a Cactus-Container module
that
> actually tests a container directly through method calls and assertions to
> see if it is in compliance, perhaps for *container developers*. If we step
Yes, but it already exists. It's called Watchdog (see
http://jakarta.apache.org/watchdog/index.html).
> back a bit and consider some sort of general framework that takes an
> interface and a batch of assertions on the use of that interface and then
> fully tests an implementation, my hunch is that it leads to somewhere very
> interesting. As you point out, though, this is outside the scope of Cactus
> at this point.
>
yes, I know some persons that are working on this.
> "How is that ? Tell me if you're still against it after my try to convince
> you ... :-)"
>
> Great! I am not avidly against anything, I am raising issues for
discussion
> and thought since the discussion about V2 to this point, as far as I can
> tell, is almost entirely positive, which, in isolation, scales to neutral.
> With a few negative data points balancing out the positive, you can feel
> even better about the positive :). I am eager to see V2 even under the
> current plan.
>
... glad to hear ! :-)
Please do continue to give your valuable feedbacks.
> Tom
Thanks
-Vincent
