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.
"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.
"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.
"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.
"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.
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
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.
"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.
Tom
