Testing JSP's with taglibs

[L Duperval]

Hi,
We have a bunch of JSP's which have broken recently because any validation we've done was manual. IOW, we launched a request and looked at the output and figured it was OK. When the JSP's went into production, someone noted that some data was missing from the output. Of course.
So that got me thinking, we need to unit test out JSP's to make sure they work correctly. I don't see this as being an easy task, especially since our JSP's uses custom-built taglibs to retrieve and display data from the database.
Our first idea is to use HttpUnit and send a request which will always return a preprogrammed set of data. Then we can make sure that the output is exactly as expected. Not the best of solutions because it's more of an integration test than a unit test.
How would I go about doing it? For example, a couple of things that bit us recently (before production, fortunately):

The Javadoc of a class was changed and improperly packaged in a client jar used in a different App server. SO when the JSP was accessed, there was an Error about the class being inconsistent (I don't remember the exact error)

A date retrieved from a SQL query was shown without the time in the HTML output

A NullPointerException because of a typo in a query

I think it may be possible to catch some of these automatically. But I'm not quite sure on the approach to use.
Any comments?
L

[Jeanne Boyarsky]

Laurent,

The Javadoc of a class was changed and improperly packaged in a client jar used in a different App server. SO when the JSP was accessed, there was an Error about the class being inconsistent (I don't remember the exact error)

I'm not sure I understand the problem with this one.

A date retrieved from a SQL query was shown without the time in the HTML output

The HttpUnit/JWebUnit add-on to Junit can help with this.

A NullPointerException because of a typo in a query

Yes, JUnit (with the database running) can catch this. You write a Junit test that really calls the query. When the query tries to run, the test will fail. We use this type of test a lot when testing back-end components.

[L Duperval]

The Javadoc of a class was changed and improperly packaged in a client jar used in a different App server. SO when the JSP was accessed, there was an Error about the class being inconsistent (I don't remember the exact error)

I'm not sure I understand the problem with this one.

We have to instances of Weblogic that speak to each other. Instance A provides an API (in the form of a jar) which instance B uses. The client API usually consists of home and remote interfaces to access beans in instance A.
Well, last week, we were going over the code and someone had entered this in the javadoc:
/**
* @Exception ARuntimeException...
*/
public void foo() {
.
.
.
throw ARuntimeException;
}
The @Exception tag was corrected to say @exception. Instance A was redeployed but the client jar was not, because technically, no code changed. Well, whenever Instance B would try to get a bean frominstance A, an error was thrown. I don't remember the exact wording but it was something to the effect that the caller was incompatible with the callee.
I find it amusing now, but it wasn't funny then.
L

[Simon Brown]

If you want to test the tags at the component (i.e. tag) level rather than unit testing the individual classes, take a look at TagUnit. Basically it allows you to test custom tags via a JSP page.
[ November 05, 2003: Message edited by: Simon Brown ]

[Jeanne Boyarsky]

Laurent,
Ok, I understand it now. Junit would not be able to check that. But running Javadoc would. If you really wanted a Junit test, you could have a test that runs Javadoc and checks the output for errors.

[Vincent Massol]

Originally posted by Simon Brown:
If you want to test the tags at the component (i.e. tag) level rather than unit testing the individual classes, take a look at TagUnit. Basically it allows you to test custom tags via a JSP page.
[ November 05, 2003: Message edited by: Simon Brown ]

or cactus ;-)
BTW, I'd be curious to compare 2 test implementations, one using Cactus and one using TagUnit. That would be nice to set them next to each other.
I also think a TagUnit JSP can be easily wrapped by a cactus test if you wish to benefit from all Cactus integration tools (Maven, Eclipse, all JUnit test runners, etc). If I understand corectly, TagUnit writes test as JSPs so that would be something like:

public class MyClassTest extends ServletTestCase (or JspTestCase)
{
  public void testXXX()
  {
    RequestDispatcher rd = theConfig.getServletContext().
      getRequestDispatcher("/path/to/tagunitjsptestcase.jsp");
    rd.forward(theRequest, theResponse);
  }
  public void endXXX(WebResponse)
  {
    // Assert returned page content here
    [...]
  }
}

[L Duperval]

Originally posted by Jeanne Boyarsky:
Laurent,
Ok, I understand it now. Junit would not be able to check that. But running Javadoc would. If you really wanted a Junit test, you could have a test that runs Javadoc and checks the output for errors.

You're right about the unit test. ONly a functional test would have shown the problem.
Javadoc would have shown the error in the javadoc (I noticed it while looking at the code in IDEA) but I'm not sure it would have told me that it changed the public API after correcting the tag error.
I honestly never thought that fixing a comment would break my code. :-)
L

[L Duperval]

Originally posted by Simon Brown:
[QB... take a look at TagUnit. Basically it allows you to test custom tags via a JSP page.[/QB]

Hey, I din't know about this one. Reading this forum has enlightened me to a whole number of other programs to do unit testing. I knew about Cactus, HttpUnit and even SQLUnit. But TagUnit and a few others are new to me. I'll have to investigate them further.
Thanks to all y'all fer sharin'!
L

[Simon Brown]

Originally posted by Vincent Massol:

public class MyClassTest extends ServletTestCase (or JspTestCase)
{
  public void testXXX()
  {
    RequestDispatcher rd = theConfig.getServletContext().
      getRequestDispatcher("/path/to/tagunitjsptestcase.jsp");
    rd.forward(theRequest, theResponse);
  }
  public void endXXX(WebResponse)
  {
    // Assert returned page content here
    [...]
  }
}

It's an interesting idea, but TagUnit actually swallows everything that is written to the outgoing JspWriter. However, the TagUnit Ant task calls a slightly different version of the TagUnit controller servlet that sends back the results of the tests as a serialized object graph, ready for the Ant task to format. You could certainly do something similar, performing assertions against the test results.