Testing GUIs Part II: JSP

Posted by Uncle Bob on 02/11/2007

How do you test JSPs outside the container, with no web server running…

Testing JSP pages.

One of the more annoying aspects of working on a web application is that you have to deploy it in order to test it. This doesn’t apply to everything of course; if you are careful with your design you can test the business rules in plain old java objects. You can test database access, interface layers, and stored procedures without the web server running. But testing the GUI – the HTML produced from the JSP files – is very hard to do unless the system has been deployed.

Lot’s of teams fall back on Selenium, Mercury, or other tools that test GUIs through the web server. However, this leads to very fragile tests that break when the format of a page changes, even though it’s content remains unchanged. Other teams solve the fragility problem by using Cactus, or the somewhat more primitive tools in HtmlUnit and HttpUnit, to inspect the generated HTML delivered to them by the running web application. We’ll talk about those techniques in another blog in this series.

In this article I will demonstrate a simple technique for testing JSP pages using JUnit and HtmlUnit, completely outside the container. The advantages of such a technique should be clear.

- You don’t have to have the container running, or even working. You can test your JSPs before you have even chosen a particular webserver.
- You can spin around the edit/compile/test loop much more quickly because you don’t have to redeploy after every edit.
- You can build your JSPs incrementally using Test Driven Development to guide their construction.

The reason that testing JSPs outside the container isn’t more common is because JSPs are designed to run inside the container. The designers never gave a lot of thought to running them outside the container. So the code generated by the JSP compiler depends on facilities supplied by the container. Even the tools that generate the JSP code expect that you already have a webapp that can be deployed. Therefore, in order to run outside the container, you somehow have to fake these facilities and tools.

Dependency Management Rant.

Why do so many designers of frameworks and tools expect you to live within their narrow world view? Why must I have a fully functional web app before I can compile my JSPs? Why must they run within the container? Information hiding has been one of the foundational tenets of good software design for decades. When will our industry begin to take it seriously?

Compiling JSPs

The first step to testing JSPs is to compile them into servlets. To do that, we first have to translate them from JSP format to JAVA. The apache project provides a tool named Jasper that does this. Invoking Jasper on a JSP named MyPage.jsp creates a JAVA source file named MyPage_jsp.java. This file can then be compiled into a servlet using your favorite IDE. (Mine is IntelliJ).

Unfortunately Jasper was not designed to be run from the command line. Or rather, half of it was, and half of it wasn’t. Jasper does in fact have a main function that takes standard command line arguments. And it is feasible to issue the command java org.apache.jasper.JspC to invoke it. However, Jasper expects the environment it runs in to be consistent with the environment of the container. It expects many the apache JAR files to be in the CLASSPATH. It also expects to see a web.xml file that describes the web application, and it wants to see a WEB-INF directory with all the appropriate web application JAR files and TLD files present. In short, Jasper expects there to be a webapp.

To make matters worse, there appear to be bugs in the version of Jasper that I am using (tomcat 5.5.20) that cause it to generate slightly incorrect code unless it is invoked in a manner that is consistent with the way that TOMCAT invokes it.

The first issue is inconvenient but is just a matter of creating the appropriate directories and files and then invoking Jaser from ANT so that the classpaths are easy to control. The second issue required a fair bit of research and experimentation to get working right. But in the end, the following ant file seems to work quite nicely. Look at the last task to see the JspC invocation.

</fileset>

</fileset>

</fileset>

</fileset>

</path>

</target>

</javac>

</target>

</target>

</copy>

</copy>

</target>

</fileset>

</fileset>

</fileset>

</fileset>

</classpath>

</java>

<jar jarfile="${build.jar.home}/jsp.jar" basedir="${basedir}/testjsp"

includes="**/jsp/**/*.class"

</target>

</project>

Of course you need all the standard files and directories beneath ${build.war.home} to make this work. If you are using custom tags in your JSPs, make sure you have all the appropriate TLD files in your tld directory.

Notice that the ANT file invokes the JspC command line, rather than using the JspC ant task that comes with TOMCAT. All the docs will tell you to use that ant task. However, I found that it doesn’t work well when you have custom tags. Maybe I’m just dumb, or maybe there is a bug in Jasper; but the only way I found to get Jasper to generate the right code was to invoke it from the command line and explicitly pass the JSP files in as command line argument!. If you depend on either the ant task or the command line to scan the whole web app for all the JSP files, it seems to generate the wrong code. (See: this blog)

Now that we have a JAVA file, let’s take a look at it. First, here’s the JSP file.

<%@ page import="com.objectmentor.library.utils.DateUtil" %>

<%@ page import="com.objectmentor.library.web.controller.patrons.LoanRecord" %>

<%@ page import="java.util.List" %>

List loanRecords = (List) request.getAttribute("loanRecords");

if (loanRecords.size() > 0) {

<tr>

<th>Title</th>

</tr>

for (int i = 0; i < loanRecords.size(); i++) {

LoanRecord loanRecord = (LoanRecord) loanRecords.get(i);

</td>

</td>

</td>

</td>

</tr>

}

</table>

}

And here is the code that Jasper created from this file.

package com.objectmentor.library.jsp.WEB_002dINF.pages.patrons.books;

import javax.servlet.*;

import javax.servlet.http.*;

import javax.servlet.jsp.*;

import com.objectmentor.library.utils.DateUtil;

import com.objectmentor.library.web.controller.patrons.LoanRecord;

import java.util.List;

public final class loanRecords_jsp extends org.apache.jasper.runtime.HttpJspBase

implements org.apache.jasper.runtime.JspSourceDependent {

private static java.util.List _jspx_dependants;

public Object getDependants() {

return _jspx_dependants;

}

public void _jspService(HttpServletRequest request, HttpServletResponse response)

throws java.io.IOException, ServletException {

JspFactory _jspxFactory = null;

PageContext pageContext = null;

HttpSession session = null;

ServletContext application = null;

ServletConfig config = null;

JspWriter out = null;

Object page = this;

JspWriter _jspx_out = null;

PageContext _jspx_page_context = null;

try {

_jspxFactory = JspFactory.getDefaultFactory();

response.setContentType("text/html");

pageContext = _jspxFactory.getPageContext(this, request, response,

null, true, 8192, true);

_jspx_page_context = pageContext;

application = pageContext.getServletContext();

config = pageContext.getServletConfig();

session = pageContext.getSession();

out = pageContext.getOut();

_jspx_out = out;

out.write('\n');

List loanRecords = (List) request.getAttribute("loanRecords");

if (loanRecords.size() > 0) {

out.write("\n");

out.write("<table class=\"list\" id=\"loanRecords\">\n");

out.write(" <tr>\n");

out.write(" <th>ID</th>\n");

out.write(" <th>Title</th>\n");

out.write(" <th>Due date</th>\n");

out.write(" <th>Fine</th>\n");

out.write(" </tr>\n");

out.write(" ");

for (int i = 0; i < loanRecords.size(); i++) {

LoanRecord loanRecord = (LoanRecord) loanRecords.get(i);

out.write("\n");

out.write(" <tr class=\"");

out.print(i%2==0?"even":"odd");

out.write("\">\n");

out.write(" <td>");

out.print(loanRecord.id);

out.write("\n");

out.write(" </td>\n");

out.write(" <td>");

out.print(loanRecord.title);

out.write("\n");

out.write(" </td>\n");

out.write(" <td>");

out.print(DateUtil.dateToString(loanRecord.dueDate));

out.write("\n");

out.write(" </td>\n");

out.write(" <td>");

out.print(loanRecord.fine.toString());

out.write("\n");

out.write(" </td>\n");

out.write(" </tr>\n");

out.write(" ");

}

out.write("\n");

out.write("</table>\n");

}

} catch (Throwable t) {

if (!(t instanceof SkipPageException)){

out = _jspx_out;

if (out != null && out.getBufferSize() != 0)

out.clearBuffer();

if (_jspx_page_context != null) _jspx_page_context.handlePageException(t);

}

} finally {

if (_jspxFactory != null) _jspxFactory.releasePageContext(_jspx_page_context);

}

Rant About Final.

Why is this class declared final? What if I had wanted to derive from it to create a testing stub? Why would anyone think that generated code is so sacrosanct that I wouldn’t want to override it.

A quick perusal of this code tells us that in order to use an instance of this servlet we need an HttpServletRequest instance, and an HttpServletResponse instance.

Looking a little closer we find that the servlet writes all the HTML to an instance of JspWriter that it gets from something called a PageContext. So, if we could create a mocked up version of JspWriter that saves all this HTML, and a mocked up version of PageContext that delivers the mocked JspWriter, then we could access the written HTML from our tests.

Fortunately the TOMCAT designers decoupled the creation of the JspWriter into a factory named JspFactory. That factory can be overridden! This means that we can get our mocked up JspWriter into the servlet without modifying the servlet. All we need is something like the following code:

class MockJspFactory extends JspFactory {

public PageContext getPageContext(Servlet servlet, ServletRequest servletRequest, ServletResponse servletResponse, String string, boolean b, int i, boolean b1) {

return new MockPageContext(new MockJspWriter());

}

public void releasePageContext(PageContext pageContext) {

}

public JspEngineInfo getEngineInfo() {

return null;

}

Now we need the mocked JspWriter. For the purposes of this demonstration, I used the following:

MockJspWriter

package com.objectmentor.library.web.framework.mocks;

import javax.servlet.jsp.JspWriter;

import java.io.IOException;

public class MockJspWriter extends JspWriter {

private StringBuffer submittedContent;

public MockJspWriter(int bufferSize, boolean autoFlush) {

super(bufferSize, autoFlush);

submittedContent = new StringBuffer();

}

public String getContent() {

return submittedContent.toString();

}

public void print(String arg0) throws IOException {

submittedContent.append(arg0);

}

public void write(char[] arg0, int arg1, int arg2) throws IOException {

for (int i=0; i<arg2; i++)

submittedContent.append(String.valueOf(arg0[arg1++]));

}

public void write(String content) throws IOException {

submittedContent.append(content);

}

// lots of uninteresting methods elided. I just gave them

// degenerate implementations. (e.g. {})

}

Don’t be concerned about the comment regarding all the unimplemented methods I elided. I’ve taken the attitude that I will only implement those methods that I need to get my tests to work. The others I leave with degenerate implementations.

My IDE was very helpful in creating these mocks. It automatically builds method prototypes and degenerate implementations for all the methods of an interface or abstract class that need implementing.

The MockPageContext, MockHttpServletRequest and MockHttServletResponse classes were created in a similar way.

MockPageContext

package com.objectmentor.library.web.framework.mocks;

import javax.servlet.*;

import javax.servlet.http.*;

import javax.servlet.jsp.*;

import java.io.IOException;

import java.util.Enumeration;

public class MockPageContext extends PageContext {

private final JspWriter out;

private HttpServletRequest request;

public MockPageContext(JspWriter out) {

this.out = out;

request = new MockHttpServletRequest();

}

public JspWriter getOut() {

return out;

}

public ServletRequest getRequest() {

return request;

}

// lots of degenerate functions elided.

}

MockHttpServletRequest

package com.objectmentor.library.web.framework.mocks;

import javax.servlet.*;

import javax.servlet.http.*;

import java.io.*;

import java.security.Principal;

import java.util.*;

public class MockHttpServletRequest implements HttpServletRequest {

private String method;

private String contextPath;

private String requestURI;

private HttpSession session = new MockHttpSession();

private Map parameters = new HashMap();

private Map attributes = new HashMap();

public MockHttpServletRequest(String method, String contextPath,

String requestURI) {

super();

this.method = method;

this.contextPath = contextPath;

this.requestURI = requestURI;

}

public MockHttpServletRequest() {

this("GET");

}

public MockHttpServletRequest(String method) {

this(method, "/Library", "/Library/foo/bar.jsp");

}

public String getContextPath() {

return contextPath;

}

public String getMethod() {

return method;

}

public String getRequestURI() {

return requestURI;

}

public String getServletPath() {

return requestURI.substring(getContextPath().length());

}

public HttpSession getSession() {

return session;

}

public HttpSession getSession(boolean arg0) {

return session;

}

public Object getAttribute(String arg0) {

return attributes.get(arg0);

}

public String getParameter(String arg0) {

return (String) parameters.get(arg0);

}

public Map getParameterMap() {

return parameters;

}

public Enumeration getParameterNames() {

return null;

}

public void setSession(HttpSession session) {

this.session = session;

}

public void setParameter(String s, String s1) {

parameters.put(s, s1);

}

public void setAttribute(String name, Object value) {

attributes.put(name, value);

}

// Lots of degenerate methods elided.

}

MockHttpServletResponse

package com.objectmentor.library.web.framework.mocks;

import javax.servlet.ServletOutputStream;

import javax.servlet.http.*;

import java.io.*;

import java.util.Locale;

public class MockHttpServletResponse implements HttpServletResponse {

// all functions are implemented to be degenerate.

}

Given these mock objects, I can now create an instance of my loanRecords_jsp servlet and start calling methods on it! Indeed, my first test case looked something like this:

public void testSimpleTest() throws Exception {

MockJspWriter jspWriter = new MockJspWriter();

MockPageContext pageContext = new MockPageContext(jspWriter);

JspFactory.setDefaultFactory(new MockJspFactory(pageContext));

HttpJspBase jspPage = new loanRecords_jsp();

HttpServletRequest request = new MockHttpServletRequest();

HttpServletResponse response = new MockHttpServletResponse();

jspPage._jspInit();

jspPage._jspService(request, response);

assertEquals("", jspWriter.getContent());

}

The test fails, as expected, because the content is a bit more than blank – but not much more. If you look carefully at the JSP file you’ll see that it calls request.getAttribute("loanRecords") and expects a List back. But since our test did not create such an attribute, the code throws an exception that is silently caught.

To get real HTML out of this servlet, we need to load up the attributes. Then we can use HtmlUnit to parse that HTML and write tests against it.

HtmlUnit is very simple to use, especially for testing generated web pages like this. There are a few gotcha’s that I described here

Here is the final test that loads the attributes, inspects the HTML with htmlUnit, and passes appropriately:

package com.objectmentor.library.jspTest.books.patrons.books;

import com.gargoylesoftware.htmlunit.*;

import com.gargoylesoftware.htmlunit.html.*;

import com.objectmentor.library.jsp.WEB_002dINF.pages.patrons.books.loanRecords_jsp;

import com.objectmentor.library.utils.*;

import com.objectmentor.library.web.controller.patrons.LoanRecord;

import com.objectmentor.library.web.framework.mocks.*;

import junit.framework.TestCase;

import org.apache.jasper.runtime.HttpJspBase;

import javax.servlet.*;

import javax.servlet.http.*;

import javax.servlet.jsp.*;

import java.util.*;

public class LoanRecordsJspTest extends TestCase {

private MockPageContext pageContext;

private MockJspWriter jspWriter;

private JspFactory mockFactory;

private MockHttpServletResponse response;

private MockHttpServletRequest request;

private WebClient webClient;

private TopLevelWindow dummyWindow;

protected void setUp() throws Exception {

jspWriter = new MockJspWriter();

pageContext = new MockPageContext(jspWriter);

mockFactory = new MockJspFactory(pageContext);

JspFactory.setDefaultFactory(mockFactory);

response = new MockHttpServletResponse();

request = new MockHttpServletRequest();

webClient = new WebClient();

webClient.setJavaScriptEnabled(false);

dummyWindow = new TopLevelWindow("", webClient);

}

public void testLoanRecordsPageGeneratesAppropriateTableRows() throws Exception {

HttpJspBase jspPage = new loanRecords_jsp();

jspPage._jspInit();

List<LoanRecord> loanRecords = new ArrayList<LoanRecord>();

addLoanRecord(loanRecords,

"99",

"Empire",

DateUtil.dateFromString("2/11/2007"),

new Money(4200));

addLoanRecord(loanRecords,

"98",

"Orbitsville",

DateUtil.dateFromString("2/12/2007"),

new Money(5200));

request.setAttribute("loanRecords", loanRecords);

jspPage._jspService(request, response);

StringWebResponse stringWebResponse = new StringWebResponse(jspWriter.getContent());

HtmlPage page = HTMLParser.parse(stringWebResponse, dummyWindow);

HtmlElement html = page.getDocumentElement();

HtmlTable table = (HtmlTable) html.getHtmlElementById("loanRecords");

List<HtmlTableRow> rows = table.getHtmlElementsByTagName("tr");

assertEquals(3, rows.size());

assertEquals("even", classOfElement(rows.get(1)));

assertEquals("odd", classOfElement(rows.get(2)));

List<HtmlTableDataCell> firstRowCells = rows.get(1).getCells();

assertEquals(4, firstRowCells.size());

List<HtmlTableDataCell> secondRowCells = rows.get(2).getCells();

assertEquals(4, secondRowCells.size());

assertLoanRecordRowEquals("99", "Empire", "02/11/2007", "$42.00", firstRowCells);

assertLoanRecordRowEquals("98", "Orbitsville", "02/12/2007", "$52.00", secondRowCells);

}

private String classOfElement(HtmlTableRow firstDataRow) {return firstDataRow.getAttributeValue("class");}

private void assertLoanRecordRowEquals(String id, String title, String dueDate, String fine, List<HtmlTableDataCell> rowCells) {

assertEquals(id, rowCells.get(0).asText());

assertEquals(title, rowCells.get(1).asText());

assertEquals(dueDate, rowCells.get(2).asText());

assertEquals(fine, rowCells.get(3).asText());

}

private void addLoanRecord(List<LoanRecord> loanRecords, String id, String title, Date dueDate, Money fine) {

LoanRecord loanRecord = new LoanRecord();

loanRecord.id = id;

loanRecord.title = title;

loanRecord.dueDate = dueDate;

loanRecord.fine = fine;

loanRecords.add(loanRecord);

}

private class MockJspFactory extends JspFactory {

private PageContext pageContext;

public MockJspFactory(PageContext pageContext) {

this.pageContext = pageContext;

}

public PageContext getPageContext(Servlet servlet, ServletRequest servletRequest, ServletResponse servletResponse, String string, boolean b, int i, boolean b1) {

return pageContext;

}

public void releasePageContext(PageContext pageContext) {

}

public JspEngineInfo getEngineInfo() {

return null;

}

This test makes sure that the generated HTML has the appropriate content contained within the rows of a table. The test does expect to see a table, and expects the rows to appear in the appropriate order. It also ensures that the rows will have alternating styles. Other than that, all issues of form and syntax are ignored.

Conclusion

The technique described here can be used to test virtually any static web page, or portion thereof outside of a container, and without a webserver running. It is relatively simple to set up; and then very easy to extend. With it, you can spin around the edit/compile/test loop very quickly, and can easily follow the rules of Test Driven Development.

Comments

Leave a response

- Brian Slesinsky about 1 hour later:
  - - No, no, what are you doing? Didn’t you see the “do not revive” request? JSP must die.

- Dean Wampler about 13 hours later:
  - - Brian (and other readers),
    - Do you have any experience with alternative Java web frameworks, like Tapestry, Cocoon, etc. I’m curious to hear other opinions about alternative frameworks. Thx.

- Uncle Bob about 17 hours later:
  - - Brian,
    - Never fear. I’ll also be doing a blog in this series on Velocity. As for JSP, I’m sorry to have to tell you this but one of the corrolaries to Murphy’s law is: The good things you do will pass away, but your mistakes live on forever.

- DaveB 4 days later:
  - - Really interesting article. I did this for a spring mvc app. I got the same code as tomcat however, when I run it I get an exception (which I make the mock propogate up).
    - Caused by: java.lang.NoSuchMethodError: javax.servlet.jsp.PageContext.getVariableResolver()Ljavax/servlet/jsp/el/VariableResolver; at org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:917) at
    - Any ideas? Does this mean that I’m running the test with the wrong things in the classpath? This wouldn’t normally happen (in tomcat) else the page would render nothing.
    - The offending line in the compiled jsp is: org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(”${myVariable}”. blah, blah);

- GregJ 12 days later:
  - - Re: Rant About Final.
    - > Why is this class declared final?
    - There are performance issues.
    - See also: http://www.javaperformancetuning.com/tips/final.shtml

- Maomao 3 months later:
  - - Uncle Bob,
    - This is really an invigorative thing. I am really looking forward of this series that cover in detail, for instance, what if there is a inside, and some other situations.

- Aaron 4 months later:
  - - May be you miss one thing – There should be a default constructor exists within class MockJspWriter:
    - public MockJspWriter() { super(BUFF_SIZE, true); }

- - - private final static int BUFF_SIZE = 1024;

- Aaron 5 months later:
  - - Uncle Bob,
    - When will you finish your next blog in this series? We, engineers working in hp, are really looking forward to see that:-)
- cheap vps over 4 years later:
  - - One of the more annoying aspects of working on a web application is that you have to deploy it in order to test it. This doesn’t apply to everything of course; if you are careful with your design you can test the business rules in plain old java objects. You can test database access, interface layers, and stored procedures without the web server running. But testing the GUI – the HTML produced from the JSP files – is very hard to do unless the system has been deployed.
    - Lot’s of teams fall cheap VPS

- - moncler over 4 years later:
    - All the docs will tell you to use that ant task. However, I found that it doesn’t work well when you have custom tags. Maybe I’m just dumb, or maybe there is a bug in Jasper

- High Protein Foods over 4 years later:
  - - That factory can be overridden! This means that we can get our mocked up JspWriter into the servlet without modifying the servlet. All we need is something like the following code
- Women's handbags over 4 years later:
  - - JSP for java??I have on idea about this ,but i think i will use it later.

- - Hotels Bucharest over 4 years later:
  - The designers never gave a lot of thought to running them outside the container. So the code generated by the JSP compiler depends on facilities supplied by the container.

- ssara over 4 years later:
  - - Working in a web application is not so easy. One has to concentrate and to be very vigilant in the tasks. Mississippi Daycare Grants

- Criminal Records over 4 years later:
  - - This test makes sure that the generated HTML has the appropriate content contained within the rows of a table. The test does expect to see a table, and expects the rows to appear in the appropriate order. It also ensures that the rows will have alternating styles. Other than that, all issues of form and syntax are ignored.

- Tenant Screening over 4 years later:
  - - The test fails, as expected, because the content is a bit more than blank – but not much more. If you look carefully at the JSP file you’ll see that it calls request.getAttribute(“loanRecords”) and expects a List back. But since our test did not create such an attribute, the code throws an exception that is silently caught.
- Flowers over 4 years later:
  - - i know what a pita GUI can be. this is some seriously in-depth coding with these prototypes

- - Mac over 4 years later:
  - The technique described here can be used to test virtually any static web page, or portion thereof outside of a container, and without a webserver running. It is relatively simple to set up; and then very easy to extend. With it, you can spin around the edit/compile/test loop very quickly, and can easily follow the rules of Test Driven Development.

- austin bible church over 5 years later:
  - - Testing JSP is really important.Thanks for describing the procedure here.This is really tremendous stuff.Love to read such informative stuff.
- bankruptcy attorney san diego over 5 years later:
  - - The best method I know of is effective, but requires up-front work by the developers, and some test framework development by at least a Visual Basic level programmer. In practice, useful tests can be developed a half step behind the GUI developers and could be done earlier if anyone ever scheduled it like that. Unfortunately, what needs to happen is sufficiently specific to the technology/functionality involved that I don’t know of a full commercial product
- louboutin sales over 5 years later:
  - - Testing GUIs Part II: JSP 114 hoo,good article!!I like the post!11