----- Original Message -----
From: "Russell Gold" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, July 15, 2001 11:21 PM
Subject: Re: Cactus Roadmap & V2 Propsal RFC
> At 10:01 PM +0100 7/15/01, Vincent Massol wrote:
> >----- Original Message -----
> >From: "Russell Gold" <[EMAIL PROTECTED]>
> > > 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 :) )
>
> If that is the case, why not embrace the IMHO simpler approach of a single
method rather than the three methods-per-test approach? Just do all of the
test set up and validation inside the servlet container and send the test
results back as a web page.
>
Yes it is simpler to have a single method but would not work for IC tests.
But you are right, if I had decided to keep the 3 methods (2 are optional by
the way) it was because I still have the idea of being able to switch back
and forth between IC and MO styles.Although having 3 methods is more complex
I find that it cleanly separates the different contracts and lets us being
able to use HttpUnit or a built in class to perform returned content
assertions (but yes, this could be implemented in a single method). Actually
it is very easy to change the implementation and remove the begin and end
method if need be (we'll see if people complain about it ... :) ). Having
them make all the kinds of test look consistent.
> >haha ! No, Cactus is passing the container's implementations of
> >HttpServletRequest, ... and _not_ it's.
>
> Hmm.. I thought your documentation indicated that you were overriding a
number of methods. I don't see how you could do that without passing your
own implementation around. And your examples all showed test scripts doing
their own instantiation and initialization of servlets rather than letting
the container do it.
>
Yes I do override a few (getServerName(),
HttpServletRequest.getDispatcher(String relativePath), ...) when I could not
do it in-container style but most of the time it come from the real
container. What I have is wrappers (exactly the same as in Servlet API 2.3
actually) around real container implementations that delegate almost all
their calls to the container's implementation. A very few are overriden.
The servlet to test is viewed as a normal java class. The real servlet is
the Cactus Redirector servlet. All the Servlet API implicit objects come
from it. So they are _real_ objects.
> > > >(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).
>
> You are giving me some ideas here, similar to an alternative approach to
in-container servlet testing. What if the session EJB is a JUnit *test
runner*?
This is what is done in Cactus using the Redirector servlet. However you
always need a "client" part for JUnit and it is nice I think to be able to
run JUnit using the standard tools you use (i.e. awt or swing test runnner
and text test runner). In that way all the tools built around JUnit still
work (Ant tasks, IDE plugins, JUnit built in test runners, ...).
>
> This is actually much easier for EJBs than servlets, since the test script
could simply use JNDI to find the beans.
I am not sure it is easier. First I think we probably need several
redirectors (although I am not sure) - one for stateful session beans, one
for stateless session beans. Also does it have any meaning to unit test
Entity Beans ? I am not sure it has as they should only be almost pure data
holders, maybe with a little logic (that can easily be tested using JUnit).
>
> >
> >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
> >}
>
> Ah, I see - that certainly makes sense as an integration point.
I have finished the unit testing of it and it seems to be working quite
well. I have not tested it functionally yet.
Note: Regarding integration of the HTTP Client part I think the best would
be for both Cactus and HttpUnit to rely on a standard HTTP client rather
than each reinventing the wheel and only supporting a few APIs. For example
it might be useful if HttpUnit was supporting webDAV calls so that you could
test DAV servers ... That's an idea, isn't it ... The problem: there isn't
a standard HTTP client at that time. There are 2 that exist : one buried in
Jigsaw (packages org.w3c.www.*) and one called HTTPClient
(http://www.innovation.ch/java/HTTPClient/) but it is under LGPL license
(which does not mix well with Apache license I seem to remember). Also there
is a new one being developed: it's called HttpClient and it's under the
jakarta-commons project. I was the http client implementation used by Slide
and that has been extracted. There is still a lot of work to do on it. I
wanted to use it but it still lacks a few useful APIs. However we are
welcome to improve it.
-Vincent
