----- Original Message -----
From: "Alex Fern�ndez" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 24, 2001 3:00 PM
Subject: Re: Test classification
> Hi again Vincent!
>
> Vincent Massol wrote:
> > > As for the role of Cactus in general, I'd like to write tests for a
> > > particular servlet in such a way that I can test using *either* mock
> > objects
> > > or in container without recompiling or changing any code in the test
> > > classes. This allows a first round of pure J2EE testing, then
progressive
> > > rounds testing different containers as necessary. In larger teams with
the
> > > proper scripts, this process allows a daily "container test."
Developers
> > > test against the mock objects on the development machines and a
> > > comprehensive project test, including containers, occurs over night or
> > > during lunch.
> > >
> >
> > hehe .... That's exactly what I have in mind currently ... The only
> > remaining problem is : how to provide that ? I have began thinking on it
but
> > have not found a perfect solution so far ... I'm more than willing to
accept
> > anyone's help on that ! I have also played with the servlet mock objects
> > implementation from the Sourceforge mockobjects project but have not
> > committed it to CVS yet as I had not finished my investigations.
> >
> > Both mock objects and Cactus have pros and cons. Merging the two would
get
> > all the pros .... Last remaining question : is it possible without
incurring
> > the cost of writing 2 test classes for each class to test ?
>
> I'd like to get this straight. You mean you don't want to keep two test
> classes, one with mock objects and another with in-container testing,
> that perform the same test?
>
> This would be kind-of-easy, you just need to call a factory that,
> depending on some config switch, returns a mock object or sets up as
> full-fledged request for the servlet container. The TestCase only needs
> to call the request's set...() methods. Then, a call to the factory's
> test() method will either instantiate the servlet and doGet() with the
> mock objects, or call the container.
>
> // create the factory for my own servlet
> TestFactory factory = new TestFactory(MyOwnServlet);
> // extract request, response and set a parameter
> TestRequest request = factory.getRequest();
> request.setParameter("name", "paul");
> TestResponse response = factory.getResponse();
> // perform the test
> factory.testServlet(request, response);
>
Yes, I had thought about doing it this way but what I don't like is that,
doing it this way, you're mocking some part of the servlet behaviour even
when doing in-container tests. For example, let's take the simple case of
testing HTTP parameter value. If you do it in mock style, you will call a
setXXX() method on your mocked HttpServletRequest. If you do it in Cactus,
you don't need to mock anything, you simply pass an HTTP parameter along
with the *real* HTTP request which is done to the Cactus Redirector. So you
are testing a bit more : you are testing retrieving an HTTP parameter in a
real situation.
To be even clearer, here is how to write it in Cactus :
public void beginHttpParam(ServletTestRequest theRequest)
{
theRequest.addParameter("param1", "some value");
}
public void testHttpParam()
{
assertEquals("some value", request.getParameter("param1"));
}
Using Mock objects :
public void testHttpParam()
{
myMockHttpServletRequest.addParameter("param1", "some value");
assertEquals("some value",
myMpckHttpServletRequest.getParameter("param1");
}
This is just an example but it is the same for most other features (like
ServletConfig, ...).
This is what bothers me currently. But I think it may be possible to do
something about it using a factory like you suggest. For example in the case
above, we could have a factory for ServletTestRequest. We will still have to
perform initialization in a beginXXX() but I don't think this is a major
problem.
> This is certainly possible with mock objects, and I think it can be done
> with Cactus too -- but you're the expert here :)
>
> However, I don't know -- in case I got it right -- if it's convenient at
> all. I mean, it's trivial that the servlet will get basically the same
> HttpServletRequest, except when the container has bugs in it.
>
> As I understand it, we want to run two different kind of tests: one
> would be a mocked-up test, that can be as comprehensive as you're
> willing to (category 1 in your classification); the in-container would
> be just a smoke-test, maybe even written by someone else, that can
> follow a sequence of operations (end-to-end, or category 3). Put another
> way, mock object tests would be "vertical", while in-container tests
> would rather be "horizontal".
>
> And yet, it would be nice to write both tests the same way.
>
> The biggest advantage I see with mock objects is that you can debug
> them! and yet, they have severe limitations when the global behavior of
> a system is tested.
>
> Un saludo,
>
Thanks for your help. I'll also have a look a the classes you wrote in
another email. Thanks for that !!
> Alex.
Vincent.
