[Httpunit-commit] CVS: httpunit/doc servletunit-intro.html,NONE,1.1 sslfaq.html,NONE,1.1 faq.html,1.
Brought to you by:
russgold
Menu
▾
▴
[Httpunit-commit] CVS: httpunit/doc servletunit-intro.html,NONE,1.1 sslfaq.html,NONE,1.1 faq.html,1.7,1.8 release_notes.txt,1.37,1.38 todo.txt,1.12,1.13
|
From: Russell G. <rus...@us...> - 2001-06-18 20:21:33
|
Update of /cvsroot/httpunit/httpunit/doc
In directory usw-pr-cvs1:/tmp/cvs-serv14775/doc
Modified Files:
faq.html release_notes.txt todo.txt
Added Files:
servletunit-intro.html sslfaq.html
Log Message:
Added tests and documentation for ServletUnit
--- NEW FILE ---
<HTML>
<HEAD>
<TITLE>ServletUnit Overview</TITLE>
</HEAD>
<BODY>
<H1>ServletUnit</H1>
<P>As a testing tool, HttpUnit is primarily designed for "black-box" testing of web sites.
In many cases that may be all you need; however, if you are developing complex servlets,
you may wish to test smaller pieces of your code. Sometimes you can isolate them into simple
tests using only JUnit. In other cases, you will want to test in a servlet environment. At this
point you have two basic approaches available. You can test in a real servlet container, using
a tool such as <A HREF="http://jakarta.apache.org/commons/cactus">Apache Cactus</A>, which has you
deploy your tests into the container along with your servlets. Or you can use a simulated servlet
container. ServletUnit takes the latter approach.</P>
<P>To test a servlet in ServletUnit, you first instantiate a <CODE>ServletRunner</CODE>
(the simulated container), and register your servlet:
<PRE><CODE>
ServletRunner sr = new ServletRunner();
sr.registerServlet( "myServlet", StatefulServlet.class.getName() );
</CODE></PRE>
Note that for complex tests, you can register multiple servlets in a single <CODE>ServletRunner</CODE>.
You are now ready to begin. You need a <CODE>ServletUnitClient</CODE>, which performs much the
same function as HttpUnit's <CODE>WebConversation</CODE> - in fact, they both extend the base
class <CODE>WebClient</CODE>, so you can use it the same way, except of course that <CODE>ServletUnitClient</CODE>
ignores the host portion of URLs in requests passed to it and goes directly to its <CODE>ServletRunner</CODE>.
This means that you can invoke the servlet and handle its response in the same way you have
been accustomed to in HttpUnit:
<PRE><CODE>
ServletUnitClient sc = sr.newClient();
WebRequest request = new PostMethodWebRequest( "http://test.meterware.com/myServlet" );
request.setParameter( "color", "red" );
WebResponse response = sc.getResponse( request );
assertNotNull( "No response received", response );
assertEquals( "content type", "text/plain", response.getContentType() );
assertEquals( "requested resource", "You selected red", response.getText() );
</CODE></PRE>
Of course, this is still black-box testing. To really take advantage of the power of ServletUnit,
you can handle your request in steps. To do this, instead of asking the client for the final response,
you ask it for an invocation context:
<PRE><CODE>
ServletUnitClient sc = sr.newClient();
WebRequest request = new PostMethodWebRequest( "http://test.meterware.com/myServlet" );
request.setParameter( "color", "red" );
InvocationContext ic = sc.newInvocation( request );
</CODE></PRE>
This invocation context provides access to the selected servlet, which has been initialized for you
with the appropriate session information, as well as the request and response objects which the
servlet will process. Now you can call methods on the servlet, on the servlet session, or on
the request and response objects. For example, given the following servlet definition:
<PRE><CODE>
public class StatefulServlet extends HttpServlet {
protected void doPost( HttpServletRequest req, HttpServletResponse resp ) throws ServletException,IOException {
resp.setContentType( "text/plain" );
writeSelectMessage( req.getParameter( "color" ), resp.getWriter() );
setColor( req, req.getParameter( "color" ) );
}
void writeSelectMessage( String color, PrintWriter pw ) throws IOException {
pw.print( "You selected " + color );
pw.close();
}
void setColor( HttpServletRequest req, String color ) throws ServletException {
req.getSession().setAttribute( "color", color );
}
}
</CODE></PRE>
you might want to test the individual methods one at a time. The following code obtains the servlet and
casts it to get access to its package-level methods (the tests should be in the same package as
the servlet to do this). It then invokes the setColor method to ensure that it is creating and
updating the session correctly.
<PRE><CODE>
StatefulServlet ss = (StatefulServlet) ic.getServlet();
assertNull( "A session already exists", ic.getRequest().getSession( false ) );
ss.setColor( ic.getRequest(), "blue" );
assertNotNull( "Session was not created", ic.getRequest().getSession( false ) );
assertEquals( "Color in session", "blue", ic.getRequest().getSession().getAttribute( "color" ) );
</CODE></PRE>
You can test the response from the servlet as well, if you invoke the code which creates it:
<PRE><CODE>
StatefulServlet ss = (StatefulServlet) ic.getServlet();
ss.writeSelectMessage( "blue", ic.getResponse().getWriter() );
WebResponse response = ic.getServletResponse();
assertEquals( "requested resource", "You selected blue", response.getText() );
assertEquals( "Returned cookie count", 1, response.getNewCookieNames().length );
</CODE></PRE>
Note that the response returned from <CODE>getServletResponse</CODE> is the actual one returned by the
servlet, without any processing by the client. For example, if the request contains a bad status or
a forward request, the client might do some additional processing, which is not done at this time.
Of course, since the response extends <CODE>WebResponse</CODE>, all of the normal HTML parsing methods
are available to examine it.
Finally, if you are writing a test which depends on the maintenance of state across servlet
invocations, you will want to reinvolve the <CODE>ServletUnitClient</CODE>, giving it a chance
to process the response, including updating its own list of cookies:
<PRE><CODE>
WebResponse response sc.getResponse( ic ); // pass the already processed InvocationContext
response = sc.getResponse( "http://test.meterware.com/ReadColorFromSession" );
assertNotNull( "No response received", response );
assertEquals( "content type", "text/plain", response.getContentType() );
assertEquals( "requested resource", "You posted blue", response.getText() );
assertEquals( "Returned cookie count", 0, response.getNewCookieNames().length );
</CODE></PRE>
This allows any subsequent request through the same client object to take advantage of the
session state established by the just completed request, just as is possible with HttpUnit.
</BODY>
</HTML>
--- NEW FILE ---
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) [Netscape]">
</head>
<body bgcolor="#FFFFFF">
<center>
<h1>
<font size=+3>Using SSL with httpunit FAQ</font></h1></center>
<h2>
Where can I get information on SSL?</h2>
<a href="http://java.sun.com/security/ssl/API_users_guide.html">from Sun
on SSL</a>
<br><a href="http://www.thawte.com/developers/contents.html">from Thawte,
a certificate vendor</a>
<br>
<a href="http://java.sun.com/products/jsse/">from the JSSE part of Sun's site</a>
<h2> What are some tools for creating and modifying certificates?</h2>
<a href="http://www.openssl.org/docs/apps/openssl.html">openssl</a> which is <a href="http://www.pseudonym.org/ssl/wwwj-index.html">also
described at pseudonym.org</a><br>
<a href="http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/keytool.html">keytool</a>
for java
<h2>
How do I create a certificate?</h2>
Create a self-signed cert via openssl, given an existing key and openssl
config file:
<p> openssl req -new -out output.pem -key my_key.pem
-days 9999 -x509 -config openssl.cnf
<p>There's also a way to do this with the java "keytool" application.
<br>
<h2>
How can I <a NAME="make my certificate trusted"></a>make my certificate
trusted by the JVM?</h2>
<p><br>If you purchased your SSL certificate from Verisign or Thawte, then
it should be automatically trusted by the "trust file" within the JVM (Sun
seems to ship JVMs with certs from these two suppliers). If you created
your own certificate, you'll need to <a href="#import my existing certificate into the trust file for">import
that cert into cacerts</a>.
<h2>
How can I <a NAME="import my existing certificate into the trust file for"></a>import
my existing certificate into the "trust file" for a JVM?</h2>
<p><br>1. Find the trusted file "cacerts" in your JRE, e.g.
<br> find /java_install -name "cacerts"
<p>2. Copy that file to a backup
<br> cp cacerts cacerts.bak
<p>3. Install your certificate into the trust file (note: the file cacerts
ships from Sun with password "changeit")
<br> keytool -import -alias <mycompany> -file mycert.pem
-keystore $JAVA_HOME/jre/lib/security/cacerts
<p>4. Verify that your cert was imported:
<br> keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts
<h2>
How can I use SSL in httpunit?</h2>
1. You need an SSL certificate intalled into the web server to be tested. That
<a href="#make my certificate trusted">certificate must be trusted</a> by the
JVM of the test rig (httpunit). That certificate must have, as its Common Name,
the exact domain name of the web server you want to secure (e.g. "www.foo.com"
or "secure.foo.com". I have not had luck with certs like *.foo.com.)
<p>2. You must enable SSL support (i.e., support for URLs that start with
"https") in your test rig's JVM. Some environments like Weblogic offer native
SSL support, which is fast compared to pure java. For Weblogic, set the
property weblogic.security.ssl.enable=true in the config file and just start
using URLs like "https://myhost". Also, there is at least one <a href="#free SSL implementation">free
SSL implementation in java</a>. <br>
<h2>
How can I use a <a NAME="free SSL implementation"></a>free SSL implementation?</h2>
There is a free <a href="http://java.sun.com/products/jsse/">SSL implementation
available in pure java from Sun</a> , although it is relatively slow, especially
in its creation of the random key to start an SSL connection (about 3 seconds
on a 600Mz PIII). To use this implementation, download the JSSE package
from the Sun URL above, then:
<p>1. Add the three key jars to your JVM's "ext" (extentions) directory;
e.g.
<br> cp jcert.jar jnet.jar jsse.jar $JAVA_HOME/jre/lib/ext/
<p>2. After the jars are in place, you must modify the file "java.security"
to allow usage of the providers found within the jars. Find the file
<br> find $JAVA_HOME -name "java.security"
<p>3. Add the following line to the file java.security:
<br> security.provider.2=com.sun.net.ssl.internal.ssl.Provider
<p>Then start using URLs like "https://myhost" within the test rig.
The HTTPS protocol will automatically cause new provider classes within
the extention jars to be employed for a java.net.URL class and its related
connections. Note that you should NOT add these jars to the CLASSPATH.
Javax jars are accessed by the JVM by their inclusion in the magic "ext"
folder.
<br>
<h2>
How do I solve a javax.net.ssl.SSLException: untrusted server cert chain?</h2>
<p><br>See how to <a href="#make my certificate trusted">make your certificate
trusted</a>.
<br>
<p>
<hr WIDTH="100%">
<p>Compiled 12 Mar 2001 by larry hamel. Please post corrections/comments
to the <a href="mailto:htt...@li...">httpunit discussion
list</a>.
</body>
</html>
Index: faq.html
===================================================================
RCS file: /cvsroot/httpunit/httpunit/doc/faq.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- faq.html 2001/05/04 21:07:07 1.7
+++ faq.html 2001/06/18 20:21:30 1.8
@@ -9,7 +9,7 @@
<LI><A HREF="#org.xml.sax">What is the org.xml.sax package?</A></LI>
<LI><A HREF="#meterware.com">Where is meterware.com?</A></LI>
<LI><A HREF="#javascript">How do I use HttpUnit to test my pages that use JavaScript?</A></LI>
-<LI><A HREF="#https">Does HttpUnit support https?</A></LI>
+<LI><A HREF="sslfaq.html">Does HttpUnit support https?</A></LI>
<LI><A HREF="#proxy">Can I use HttpUnit through a proxy server?</A></LI>
<LI><A HREF="#charset">Why isn't HttpUnit handling my non-English pages?</A></LI>
<LI><A HREF="#utf8">HttpUnit fails with an IllegalArgumentException: sun.io.CharToByteUTF-8, what do I do?</A></LI>
@@ -38,11 +38,6 @@
Unfortunately, you can't. HttpUnit does not support any dialect of JavaScript. I have been shown a JavaScript library and it is possible
that I will one day add JavaScript support, but since I use it very little in my own development, and since it looks like a lot of work,
it is not a major priority for me. If you feel ambitious enough to add JavaScript support yourself, I would be happy to accept submissions.
-
-<A NAME="https"><H2>Does HttpUnit support https?</H2></A>
-Yes, as long as you have the <A HREF="http://java.sun.com/products/jsse/">JSSE extension</A> installed.
-Download this extension and install
-its three jars in your classpath.
<A NAME="proxy"><H2>Can I use HttpUnit through a proxy server?</H2></A>
Yes. HttpUnit uses java.net.HttpURLConnection, so the
Index: release_notes.txt
===================================================================
RCS file: /cvsroot/httpunit/httpunit/doc/release_notes.txt,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- release_notes.txt 2001/06/13 16:38:19 1.37
+++ release_notes.txt 2001/06/18 20:21:30 1.38
@@ -9,59 +9,43 @@
Limitations: HttpUnit does not support JavaScript
-
Revision History:
+
+18-Jun-2001 1.2.5
Acknowledgements:
Thanks to Rolf Schmidiger for corrected behavior when failing to find a site
Thanks to Tom Watkins, Deepa Dihr, Marcos Tarruella for their implementation of
PutMethodWebRequest
+ Thanks to Larry Hamel for writing the SSL FAQ
-11-Jun-01
Additions:
- 1. Added getInputStream method in WebResponse to support non-text responses.
- 2. Matching of text in web pages is now controlled by the HttpUnitOption property
+ 1. selectFile() now can infer file content type for the most common file extensions:
+ text, txt, gif, jpg, jpeg, png, html, htm and zip.
+ 2. A new version of selectFile allows explicit specification of file content type
+ which will override any inferred type.
+ 3. <button> tags are now recognized as submit buttons if their type is "submit"
+ or not specified.
+ 4. Reading the character set from a <meta> tag is now supported.
+ 5. Added PutMethodWebRequest
+ 6. PostMethodWebRequest now has a constructor which allows its contents to be
+ taken from an InputSource, like PutMethodWebRequest
+ 7. Added ServletUnitClient and InvocationContext to servletunit to
+ permit more granular testing of servlets (still not well documented)
+ 8. Added getInputStream method in WebResponse to support non-text responses.
+ 9. Matching of text in web pages is now controlled by the HttpUnitOption property
'matchesIgnoreCase'. The default behavior is as before - matches are not case sensitive
-
- 6-Jun-01
-Additions:
- 1. Added ServletUnitClient and InvocationContext to servletunit to
- permit more granular testing of servlets
- 4-Jun-01
-Additions:
- 1. Added PutMethodWebRequest
- 2. PostMethodWebRequest now has a constructor which allows its contents to be
- taken from an InputSource, like PutMethodWebRequest
-
-31-May-01
Problems corrected:
1. Now throws HttpNotFoundException rather than NullPointerException when
unable to connect to a web site
2. I/O exceptions when accessing a site are now thrown, rather than being
turned into RuntimeException.
-
-22-May-01
-Additions:
- 1. Reading the character set from a <meta> tag is now supported.
-
-21-May-01
-Additions:
- 1. selectFile now infers file content for zip extension
- 2. <button> tags are now recognized as submit buttons if their type is "submit"
- or not specified.
-
-16-May-01
-Additions:
- 1. selectFile now can infer file content type for the most common file extensions:
- text, txt, gif, jpg, jpeg, png, html, and htm.
- 2. A new version of selectFile allows explicit specification of file content type
- which will override any inferred type.
-
Configuration changes:
1. The build.xml file has been changed to use a specified directory of dependant jars
rather than the system classpath. This requires at least ant 1.3. It is no longer
necessary to specify the classpath parameter when running the unit tests.
+
5-May-01 1.2.4
Acknowledgements:
Index: todo.txt
===================================================================
RCS file: /cvsroot/httpunit/httpunit/doc/todo.txt,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- todo.txt 2001/06/13 16:38:20 1.12
+++ todo.txt 2001/06/18 20:21:30 1.13
@@ -1,4 +1,5 @@
o Support <META HTTP_EQUIV=REFRESH tags>
+o Support optional tags which hide their contents (as in IFRAME, OBJECT, etc.)
o Support IFRAME tag
o Support reset button detection
o Support _new frame tag
|
