----- Original Message -----
From: "Russell Gold" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, July 15, 2001 8:59 PM
Subject: Re: Cactus Roadmap & V2 Propsal RFC
> At 9:36 AM +0100 7/15/01, Vincent Massol wrote:
> >From: "Thomas Calivera" <[EMAIL PROTECTED]>
> > > 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).
>
> So if they are not the same kind of tests, what is the advantage of having
the same framework do them? Most of the suggestions I have seen assumed
that it was valuable and reasonable to switch back and forth between MO and
IC testing by throwing a switch. I think that you are correct that they are
different, and therefore it is not clear to me that configuration selection
is meaningful. But if that is the case, how does putting them in the same
framework help?
>
See my answer to Thomas on the subject. I'd still like to put them in the
same framework because Cactus' goal is hegemonistic ... :-) (just kidding).
Cactus's goal is to encompass server-side unit testing (and not specifically
IC testing). Whatever the technique just as long as it provides tools for
unit testing server side code. IC cannot do it alone, let's bring MO in ...
:)
> >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.
>
> Could you explain a bit more about this "consistent way of writing tests"?
You seem to have something in mind, but I cannot tell what it is. And why
do you feel a need to have so many test case specializations. HttpUnit
manages to provide support for both functional and mock-object tests of
servlets w/o specializing TestCase at all. Could you explain your approach?
The web page proposal contains virtually no technical details.
Writing a test case in HttpUnit is very different than writing a test case
in Cactus ... A consistent way of writing test cases means that you would
use the same interfaces, use for example beginXXX() and endXXX() methods,
... It means that you won't have to learn 2 or more APIs to write a test
case. I wish I could have only a single TestCase class instead of several
(maybe for v3 :) )
>
> >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 ...
>
> I definitely agree that documentation is key, and you have done a much
better job of it than I have :)
It will get even better in the future ... Let's race ... :-)
>
> > > 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.
>
> Very true. And that does BTW lead me to wonder about the details of your
current in-container approach. Among the things that containers do specially
is create their implementations of HttpServletRequest, HttpServletResponse,
ServletContext and so on. But aren't you passing around Cactus
implementations of these classes? Surely a true in-container framework
needs to somehow supply the container implementations of these classes - and
also initialize the servlets according to the directions in the web.xml file
as the servlet container does it. I am sure that I have missed something
(again), but if you are supplying your own implementations, aren't you
hiding this matter of proprietary implementations?
>
haha ! No, Cactus is passing the container's implementations of
HttpServletRequest, ... and _not_ it's. So you're right you could call
Cactus a "true" in-container framework ! :-) (BTW it does take the
informations from web.xml)
> > > 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).
>
> Then it may be that you are focusing your efforts in the wrong place. You
already have a satisfactory in-container testing framework. HttpUnit can
serve as a complementary framework for mock object and functional tests. But
what may be missing is a framework for EJB testing. To be sure, you can do
some functional tests of EJBs from an application container, but I don't
know of anything that allows testing of EJB internals. Have you given any
thought to that?
EJB testing is part of the roadmap for Cactus (check the roadmap page on the
Cactus web site). I have given it some thoughts already but I am still not
sure how it will work out (the idea being to provide generic EJB redirectors
which are EJB themselves and thus could provide access to real container
implicit objects - namely the EJB context object).
FYI, I have just finished implementing the endXXX() handling in V2 and it
works in the following way :
As a test writer you have 2 ways of writing your endXXX() method depending
on what you wish to do inside that method :
1/ If you only wish to do some very simple verifications and asserts, you
would write it as follows :
public void endXXX(org.apache.commons.cactus.WebRequest theRequest)
{
// some asserts (provides access to data as input stream, as text and
provides accessors to HTTP cookies and headers). Basically the same as in
cactus V1.x
}
2/ If you wish to perform sophisticated assertions, like verifiying that the
returned HTML page contains a table with a given background color, then you
would need to have the HttpUnit jar in your classpath and write it as
follows :
public void endXXX(com.meterware.httpunit.WebRequest theRequest)
{
// perform complex asserts using the full power of HttpUnit
}
Thanks for your comments.
-Vincent
