+1 for integrating HttpUnit within Cactus (to benefit from Http Unit
assertion facilities for asserting the result of a page executed on the
server, and use it in endXXX() )
Good idea !
-Vincent
----- Original Message -----
From: "Jari Worsley" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 29, 2001 6:07 PM
Subject: [cactus]A Heath Robinson lash up with HttpUnit
>
> I have been having a "heath Robinson-esque" bit of fun with cactus and
> HttpUnit this afternoon.
>
> Why? because I want to know how I can set up a test of a JSP page that
> is independent of the servlet code that is used to populate
> request,session and application scope (in JSP speak). The idea being to
> execute a bit of setup code on the server before doing a forward to a
> JSP page.
>
> I also don't see the point in maintaining two sets of source code for
> the client part of an Http connection. HttpUnit provides good client
> side code, it seemed sensible to see how it might be useful (well it
> seemed sensible this morning anyway ;).
>
>
> You can get get a straight TestCase to call a ServletTestCase through
> the redirector using something like:
>
> public void testTestCall()
> throws Exception
> {
> WebConversation conversation = new WebConversation();
> WebRequest request = new GetMethodWebRequest(
> "http://localhost:8080/test/ServletRedirector"; );
> request.setParameter(ServiceDefinition.CLASS_NAME_PARAM,
> "testpackage.TestForwardPage");
> request.setParameter(ServiceDefinition.METHOD_NAME_PARAM,
> "testHandle");
> request.setParameter( ServiceDefinition.SERVICE_NAME_PARAM,
>
> ServiceEnumeration.CALL_TEST_SERVICE.toString());
> WebResponse response = conversation.getResponse( request );
> assertEquals(response.getText().indexOf("login") != -1, true);
> }
>
> so that you can write server side code to setUp the JSP test.
>
> Some more small changes:
> ======================
>
> with some small changes to HttpUnit code, namely making the class
> HttpWebResponse public and making it's constructor public , (in package
> com.meterware.httpunit ), you can use the HttpWebResponse class within a
> cactus test:
>
> public void testHandle()
> throws Exception
> {
> _forward.handle(request, response, _dispatcher);
> }
> // the test just forwards to a page, in this case a simple index.jsp
> page containing simple html
>
> public void endHandle(HttpURLConnection con)
> throws Exception
> {
>
> // ok. try to make a WebResponse.
> HttpWebResponse resp = new HttpWebResponse("foo", null,
> con);
> assertEquals(resp.getText().indexOf("login") != -1, true);
> }
>
> - by making HttpWebResponse public, you can give it nonsense for the
> target and URL (1st and 2nd params), then give it the HttpURLConnection,
> and get back an HttpWebResponse object, allowing calls like getText(),
> getForms(), etc...
>
>
> WHY!!!!
> =======
> Now this seems to me a bit too complicated, and there must be a better
> way of doing things.
>
> Cactus is good for testing server side code, but not at testing the
> result that is sent back to the client.
>
> HttpUnit is good at testing the result back at the client, but has no
> facility to set test conditions on the server. so it can only be used
> for a test of the full functionality of a site, rather than for testing
> a site in parts (e.g. testing JSP and Servlet code separately).
>
>
> Why do i want to do this? because in my organization the authors of
> servlet and JSP code are different people. It would be good to be able
> to test the JSP and Servlets independently of each other, and just
> provide an interface between the two for both groups to program to -
> sort of a "JSP Contract".
>
> It seems to me that a "mating" in some way of HttpUnit and Cactus
> functionality would allow you to perform unit testing of the View part
> of a Model 2 application separately from the Model and Controller part.
>
>
> so, daft idea, or mileage in it? I would still like to know what tools
> and techniques others are using to test just the JSP component of an
> application.
>
> Jari
>
> --
> Jari Worsley
> Senior Programmer
> Hyperlink Interactive Ltd
>
