[Httpunit-commit] CVS: httpunit/doc release_notes.txt,1.72,1.73 servletunit-intro.html,1.1,1.2

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Update of /cvsroot/httpunit/httpunit/doc
In directory usw-pr-cvs1:/tmp/cvs-serv28022/doc

Modified Files:
	release_notes.txt servletunit-intro.html 
Log Message:
prepare for 1.3 release

Index: release_notes.txt
===================================================================
RCS file: /cvsroot/httpunit/httpunit/doc/release_notes.txt,v
retrieving revision 1.72
retrieving revision 1.73
diff -u -r1.72 -r1.73

--- release_notes.txt	2001/11/27 19:51:27	1.72
+++ release_notes.txt	2001/11/28 18:25:33	1.73
@@ -9,90 +9,61 @@
 
 Limitations:
     1. HttpUnit does not support JavaScript
-    2. JDK 1.2 or higher is required
+    2. JDK 1.2 or higher is now required
 
 
 Revision History:
-27-Nov-2001
-Acknowledgements:
-    Thanks to Peter Roßbach for catching some typos in the tutorial.
-    Thanks to Benoit Xhenseval for optimizing the use of DOMs and StringBuffers.
-
-Additions:
-   1. The tutorial now includes an explanation of security testing in ServletUnit
-   2. Archives are now rooted with the build name
-   3. HttpUnit is now more efficient in its use of memory, pre-allocating buffers to the most likely needed size and
-      avoiding unnecessary copying of DOMs.
+28-Nov-2001 1.3.0
 
-26-Nov-2001
 Acknowledgements:
-    Thanks to Oliver Imbusch for finding and supplying a fix for bad parsing of link URLs with parameters and fragments.
-
-Additions:
-   1. ServletUnit now handles protected URLs defined in web.xml, along with both Basic and Form authentication. Logins
-      with non-blank usernames are also accepted, with the password being interpreted as a comma-separated list of
-      role names.
-   2. ServletUnit now handles servlet initialization parameters defined in web.xml
-
-Problems fixed:
-   1. ServletUnit now handles URL-encoded parameter names properly.
-
-14-Nov-2001
-Acknowledgements:
+    Thanks to Oliver Imbusch for finding and fixing problems with parsing of encoded link parameter names and values and
+        of link URLs with parameters and fragments.
+    Thanks to Paul Frantz and Dave Glowacki for finding and fixing problems with parsing of link parameter names without values.
+    Thanks to Didier Besset for new WebForm methods: hasParameterNamed and hasParameterStartingWithPrefix
+    Thanks to Peter Roßbach for catching some typos in the tutorial.
     Thanks to Benoit Xhenseval for adding a mechanism to handle HTML parser errors.
-
-Additions:
-   1. ServletUnit now compiles against Servlet 2.3
-   2. HttpUnitOptions now has methods addHtmlErrorListener and removeHtmlErrorListener. If a listener is registered,
-      it will be invoked for every error or warning generated by the parser, indicating the URL, line and column number
-      of the error and a textual description of the problem.
-
-Problems fixed:
-   1. HttpUnit should now be more tolerant of missing character encodings
-
-12-Nov-2001
-Problems fixed:
-   1. WebSphere cookie values ending with "=" or "==" are now handled.
-
- 9-Nov-2001
-
-Acknowledgements:
-    Thanks to Dave Glowacki for finding and fixing another problem with parsing of link parameter names without values.
-
-Problems Fixed:
-    1. Links with parameters with no "=" were being treated as though they had "="
-
- 8-Nov-2001
-Acknowledgements:
+    Thanks to Benoit Xhenseval for optimizing the use of DOMs and StringBuffers.
     Thanks to Bradley Smith for implementing getParameterNames in ServletUnit.
 
 Problems fixed:
-   1. ServletUnit was not decoding its request parameters
-   2. ServletUnit's HttpRequest.getParameterNames method was not implemented
-
-Additions:
-   1. ServletUnit now handles web.xml partially, supporting mapping of single paths to a servlet class
-   2. Disabled submit buttons may no longer be selected from a form
-   3. When enabled, parameter validation now prevents changes to readonly controls.
-   4. It is now possible to obtain the reason message associated with the status code, either from
-      HttpException.getResponseMessageweb() or if exceptions are disabled, from WebResponse.getResponseMessage()
-
- 5-Nov-2001
-
-Acknowledgements:
-    Thanks to Oliver Imbusch for finding and fixing a problem with parsing of encoded link parameter names and values.
-    Thanks to Paul Frantz for finding and fixing a problem with parsing of link parameter names without values.
-    Thanks to Didier Besset for new WebForm methods: hasParameterNamed and hasParameterStartingWithPrefix
-
-Problems Fixed:
     1. Links with parameters whose names were encoded were being mis-parsed
     2. Links with empty parameter values were being mis-parsed
     3. Most references to TestCase.assert have been renamed to assertTrue in order to prepare for JDK 1.4 and JUnit 3.7
        compatibility. HttpUnitTest and ServletUnitTest implement assertTrue to continue support for JUnit 3.6 and earlier.
-    4. Some incompatibilities with JDK 1.1 had been inadvertantly introduced.
+    4. ServletUnit was not decoding its request parameters and names
+    5. ServletUnit's HttpRequest.getParameterNames method was not implemented
+    7. WebSphere cookie values ending with "=" or "==" are now handled.
+    8. HttpUnit should now be more tolerant of missing character encodings
 
 Additions:
-    1. It is now possible to check a WebForm for the presence of a named parameter.
+  Content and parsing enhancements
+      1. It is now possible to check a WebForm for the presence of a named parameter.
+      2. Disabled submit buttons may no longer be selected from a form
+      3. When enabled, parameter validation now prevents changes to readonly controls.
+      4. It is now possible to obtain the reason message associated with the status code, either from
+         HttpException.getResponseMessageweb() or if exceptions are disabled, from WebResponse.getResponseMessage()
+      5. HttpUnitOptions now has methods addHtmlErrorListener and removeHtmlErrorListener. If a listener is registered,
+         it will be invoked for every error or warning generated by the parser, indicating the URL, line and column number
+         of the error and a textual description of the problem.
+
+  ServletUnit enhancements
+      6. ServletUnit now compiles against Servlet 2.3
+      7. ServletUnit now handles web.xml partially, supporting:
+         a. mapping of exact paths to a servlet class
+         b. protected URLs (exact paths only)
+         c. Basic and Form authentication
+         d. Servlet initialization parameters
+
+   Documentation and Packaging
+      8. There is now the beginnings of a tutorial, focused on ServletUnit but covering much of the HttpUnit API
+         in doc/tutorial
+      9. Archives are now rooted with the build name, following unix conventions
+
+   Optimizations
+     10. HttpUnit now pre-allocates StringBuffer instances to their most likely size
+     11. DOMs are no longer copied when passed internally'
+     12. ByteTag objects no longer allocate Hashtable unless required
+
 
 25-Oct-2001 1.2.7
 

Index: servletunit-intro.html
===================================================================
RCS file: /cvsroot/httpunit/httpunit/doc/servletunit-intro.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- servletunit-intro.html	2001/06/18 20:21:30	1.1
+++ servletunit-intro.html	2001/11/28 18:25:33	1.2
@@ -7,25 +7,26 @@
 <BODY>
 <H1>ServletUnit</H1>
 
-<P>As a testing tool, HttpUnit is primarily designed for "black-box" testing of web sites. 
+<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 
+a tool such as <A HREF="http://jakarta.apache.org/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:
+<P>To test a servlet in ServletUnit, you first instantiate a <CODE>ServletRunner</CODE>
+(the simulated container), and register your servlets:
 <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>.
+Note that for complex tests, you can register multiple servlets in a single <CODE>ServletRunner</CODE> or initialize
+the <code>ServletRunner</code> with the name of a web.xml file from which to read an entire application full of servlets.
 
 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 
+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>.
 
@@ -44,7 +45,7 @@
 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>  
+<PRE><CODE>
         ServletUnitClient sc = sr.newClient();
         WebRequest request   = new PostMethodWebRequest( "http://test.meterware.com/myServlet" );
         request.setParameter( "color", "red" );
@@ -55,7 +56,7 @@
 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>  
+<PRE><CODE>
     public class StatefulServlet extends HttpServlet {
 
         protected void doPost( HttpServletRequest req, HttpServletResponse resp ) throws ServletException,IOException {
@@ -63,7 +64,7 @@
             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();
@@ -75,10 +76,10 @@
     }
 </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>  
+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 ) );
 
@@ -88,7 +89,7 @@
 </CODE></PRE>
 
 You can test the response from the servlet as well, if you invoke the code which creates it:
-<PRE><CODE>  
+<PRE><CODE>
         StatefulServlet ss = (StatefulServlet) ic.getServlet();
         ss.writeSelectMessage( "blue", ic.getResponse().getWriter() );
 
@@ -96,7 +97,7 @@
         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 
+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
@@ -105,7 +106,7 @@
 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>  
+<PRE><CODE>
         WebResponse response sc.getResponse( ic );   // pass the already processed InvocationContext
 
         response = sc.getResponse( "http://test.meterware.com/ReadColorFromSession" );
@@ -116,7 +117,13 @@
 </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.
+
+If you are using a web.xml file to define your servlets, you can also test protected resources. ServletUnit supports
+both Basic and Form authentication, and handles them just as HttpUnit does. For Basic authentication, you must call
+setAuthorization passing a username and password, while Form authentication is handled just like any other form. Since
+ServletUnit does not maintain a database of users, it will accept any user/password combination as valid, and treat the
+password as a comma-separated list of role names.
 </BODY>
-</HTML>  
-    
-    
+</HTML>
+
+



