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.
>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.
> > >(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 actually much easier for EJBs than servlets, since the test script could
simply use JNDI to find the beans.
>
>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.
--
------------------------------------------------------------------------
Russell Gold | "... society is tradition and order
[EMAIL PROTECTED] | and reverence, not a series of cheap
| bargains between selfish interests."
http://www.httpunit.org | - Poul Anderson, "Iron"
