Frequently Asked Questions

  1. Why can't I unzip the download library?
  2. What is the org.xml.sax package?
  3. I don't understand how the ... API works.
  1. Does HttpUnit support https?
  2. Can I use HttpUnit through a proxy server?
  3. Why isn't HttpUnit handling my non-English pages?
  4. The server is not sending a valid content type. How do I test HTML pages anyway?
  1. HttpUnit is not finding the buttons and parameters in my forms. What is wrong?
  2. Why can't I change hidden parameters?
  1. How do I use HttpUnit to test my pages that use JavaScript?
  2. JavaScript is not being executed at all. Why not?
  3. How do I handle a page that uses JavaScript features that HttpUnit does not support?
  1. How can I see the servlet session between calls?
  2. Can I use JSPs with ServletUnit?

Problems getting started

Why can't I unzip the download library?

HttpUnit is archived using the classes in the java.util.zip package. Some older Unzip programs cannot understand this format. If you are using WinZip, stick to version 7.0 or later.

What is the org.xml.sax package?

You may be getting compile or runtime errors asking for the org.xml.sax package. You need to have xerces or another XML parser in your classpath. Xerces is included in the download.

I don't understand how the ... API works.

The best way to understand how the API works is to look at the samples in the test directory. This contains an example of just about every feature of the library and is used to verify that they continue to work. Of course, if you know a tech writer who would like to contribute to improving the documentation, that is always welcome.

Server Issues

Can I use HttpUnit through a proxy server?

Yes. Call WebClient.setProxyServer( host, port ) before sending your request.

Why isn't HttpUnit handling my non-English pages?

When no Content-Type header is specified, HTML 1.1 says that the character set is to be taken as iso-8859-1. Unfortunately, some HTTP servers do not send this parameter correctly, and many browsers incorrectly use this as an indication that they should determine the character set in some other fashion. To imitate this behavior, HttpUnit allows you to set the expected character set for future pages by calling HttpUnitOptions.setDefaultCharacterSet(). This setting will not apply to those pages for which the server specifies the character set.

Non-English form handling is supported as well. Any parameter values entered into a form will be encoded as the same character set as the document containing the form. The server code will then have to handle those characters appropriately. In Java, that would be converting them to Unicode with statements such as

String rawName = request.getParameter( "name" );
String japaneseName = new String(name.getBytes("8859_1"),"EUC_JP");
where the proper encoding should be substituted for "EUC_JP". The getBytes call is needed to extract the raw bytes from the parameter string.

The server is not sending a valid content type. How do I test HTML pages anyway?

By default, HttpUnit assumes a content type of "text/plain" unless the server sends the Content-Type header to override it, as most servers do. If yours is not, you can call
HttpUnitOptions.setDefaultContentType( "text/html" );
before running your tests. If you are using JUnit, call this method in your setUp() method.

Form Handling Problems

HttpUnit is not finding the buttons and parameters in my forms. What is wrong?

Usually this indicates some poor nesting of <form> tags. Browsers are extremely forgiving of bad HTML, even handling cases where it is impossible to turn that HTML into a DOM. When a parser encounters such code, it tries to "fix it" which may not generate exactly the intended results. As of version 1.5.2, HttpUnit is a lot more forgiving, considering controls to belong to the last opened <form> tag, even it was presumed to have been closed. This seems to match what most browsers do. Under some circumstances switching among the supported parsers may give different results. Note that JTidy can display error messages to tell you when there are problems with your HTML. To see them, call HttpUnitOptions.setParserWarningsEnabled( true ) before retrieving your HTML page.

Why can't I change hidden parameter values?

By default, HttpUnit verifies any parameter value changes against the form containing them. Since a user cannot directly change hidden parameters, HttpUnit stops you from doing it in your code. If you have to change these values, you have a couple of choices:

JavaScript support

How do I use HttpUnit to test my pages that use JavaScript?

You should not have to do anything special; however, not all JavaScript constructs are supported as yet. See the list of supported JavaScript features for more information.

JavaScript is not being executed at all. Why not?

If you do not have the Rhino JAR (js.jar) in your classpath, JavaScript features do not work.

How do I handle a page that uses JavaScript features that HttpUnit does not support?

If you call
HttpUnitOptions.setExceptionsThrownOnScriptError( false );
problems will recorded but will not throw exceptions. You can see the list of problems detected by calling
HttpUnitOptions.getScriptErrorMessages();

ServletUnit usage

How can I see the servlet session between calls?

Servlet session is maintained on the server. Therefore, if you want to do this, you must be using ServletUnit. Once you have that working, you can get take advantage of the power of ServletUnit to get at internal values, using the InvocationContext object. For example,

ServletUnitClient client = ...          // the client you have been using
client.getResponse( servlet-url );      // invoke your servlet normally

// now get an invocation context using the same URL used to invoke the servlet
InvocationContext ic = client.newInvocationContext( servlet-url );
// obain the session just used. Note: pass false to avoid creating it if it does not already exist
HttpSession session = ic.getRequest().getSession( false );
Now you can examine the contents of the session to see what the servlet left in it.

Can I use JSPs with ServletUnit?

Absolutely! But since you are now emulating the servlet environment, you will need to make sure that you have access to the relevant classes. By default, ServletUnit is configured to use Jasper, the JSP engine which is part of Tomcat. You will therefore need the Jasper jar in your classpath, along with any on which it depends. Once you have done that, your JSPs should run, just as they would in Tomcat.