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
