Frequently Asked Questions
- Why can't I unzip the download library?
- What is the org.xml.sax package?
- I don't understand how the ... API works.
- Does HttpUnit support https?
- Can I use HttpUnit through a proxy server?
- Why isn't HttpUnit handling my non-English pages?
- The server is not sending a valid content type. How do I test HTML pages anyway?
- HttpUnit is not finding the buttons and parameters in my forms. What is wrong?
- Why can't I change hidden parameters?
- How do I use HttpUnit to test my pages that use JavaScript?
- JavaScript is not being executed at all. Why not?
- How do I handle a page that uses JavaScript features that HttpUnit does not support?
- How can I see the servlet session between calls?
- 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
callHttpUnitOptions.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:
- If you call
HttpUnitOptions.setParameterValuesValidated( false )
before calling getRequest on your form,
the request will be created with validation disabled and you will be able to set any values you like. Note that in such a case
the order of parameters in the request is not guaranteed, in case your server cares about such things (servlets do not).
- You can call
<form>.getScriptableObject().setParameterValue( <name>, <value> );
to change
the underlying value in the form. This will behave the way JavaScript does - resetting the form will now restore this value,
rather than the original one.
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 callHttpUnitOptions.setExceptionsThrownOnScriptError( false );
problems will
recorded but will not throw exceptions.
You can see the list of problems detected by callingHttpUnitOptions.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.