Hi Richard, It is a bug that was introduced when Cactus switched to using HttpClient in version 1.4. I have fixed it in Cactus 1.4.1 that I will try to deliver later today.
I have also added the HttpUnit test to the Cactus test suite (I had wanted to do that a while ago but somehow I had some issues and then I forgot about it). Thanks -Vincent > -----Original Message----- > From: Hirsch Richard [mailto:[EMAIL PROTECTED]] > Sent: 26 August 2002 12:55 > To: 'Cactus Users List' > Subject: AW: HTTPUnit Integration > > Hi Vincent, > > I am using the TestServletTestCase_HttpUnit.java from the Cactus release. > The class works in the Tomcat 4.0 but in our environment which includes > Tomcat 3.2.3 and Jboss 2.4.3, it fails. When I tried writing my own endXXX > method with the cactus Webresponse object it worked but one with the > httpunit Webresponse object kept returning an empty response. > > One of the advantages of both being in Europe is the fast email > turn-around.... > > Another question: why didn't you include the httpunit unit test in the > Alltests class? Since the httpunit jar is already in the distribution, you > could include the tidy.jar as well. > > Thanks, > > Dick > > -----Ursprungliche Nachricht----- > Von: Vincent Massol [mailto:[EMAIL PROTECTED]] > Gesendet: Montag, 26. August 2002 13:20 > An: 'Cactus Users List' > Betreff: RE: HTTPUnit Integration > > > Hi Richard, > > Your test does indeed return the correct string in the HTTP response : > > > 12:58:19,339 [main] INFO httpclient.wire - << > "something > > to > > return for the test" > > The <webresult></webresult> simply means to Cactus that there were no > error while executing the tests. Cactus does 2 call for each test, one > call to execute the test and another one to get the result of the test, > i.e. ok or not ok (if not ok, it gets the exception). > > Thus, your test did succeed on the server side. The problem is on the > client side. Could you send your endHttpUnitGetText() method ? > > Thanks > -Vincent > > > -----Original Message----- > > From: Hirsch Richard [mailto:[EMAIL PROTECTED]] > > Sent: 26 August 2002 12:08 > > To: 'Cactus Users List' > > Subject: HTTPUnit Integration > > > > I'm having some trouble integrating httpunit into my cactus > environment. > > We > > are using Tomcat 3.2.3. Could that be my problem? I am getting an > empty > > WebResponse. I am using the testHttpUnitGetText class from the cactus > > distribution (jakarta-cactus-13-1.4) as well as the other > jars(httpunit, > > jnuit, etc.) > > > > Notice that the httpclient.wire method has the correct value but the > > <webresult> element is empty ("<webresult></webresult>"). > > > > Thanks, > > > > Dick > > > > Here is the log4j trace: > > > > 12:58:17,876 [main] DEBUG n.TestServletTestCase_HttpUnit - > ------------- > > Test: testHttpUnitGetText > > 12:58:18,017 [main] DEBUG httpclient.HttpClient - > > HttpClient.startSession(String,int,boolean): Host:localhost Port:8080 > > HTTPS:false > > 12:58:18,037 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.HttpConnection > > 12:58:18,037 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.open() > > 12:58:19,178 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.execute(HttpState,HttpConnection) > > 12:58:19,178 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.execute(): looping. > > 12:58:19,178 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.writeRequest(HttpState,HttpConnection) > > 12:58:19,188 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.writeRequestLine(HttpState,HttpConnection) > > 12:58:19,188 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.write(byte[]) > > 12:58:19,188 [main] INFO httpclient.wire - >> "GET > > > /webesa/ServletRedirector?Cactus_TestMethod=testHttpUnitGetText&Cactus_T > es > > tC > > > lass=com.db.cfc.test.app.gen.TestServletTestCase_HttpUnit&Cactus_Automat > ic > > Se > > ssion=true&Cactus_Service=CALL_TEST HTTP/1.1 > > " > > 12:58:19,188 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.writeRequestHeaders(HttpState,HttpConnection) > > 12:58:19,298 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.write(byte[]) > > 12:58:19,298 [main] INFO httpclient.wire - >> > > "Content-type: application/x-www-form-urlencoded > > " > > 12:58:19,298 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.write(byte[]) > > 12:58:19,298 [main] INFO httpclient.wire - >> "Host: > > localhost > > " > > 12:58:19,298 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.write(byte[]) > > 12:58:19,298 [main] INFO httpclient.wire - >> "User- > > Agent: > > Jakarta HTTP Client/2.0.0a1 > > " > > 12:58:19,298 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.writeLine() > > 12:58:19,298 [main] INFO httpclient.wire - >> \r\n > > 12:58:19,298 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.readResponse(HttpState,HttpConnection) > > 12:58:19,298 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.readStatusLine(HttpState,HttpConnection) > > 12:58:19,298 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.readLine() > > 12:58:19,339 [main] INFO httpclient.wire - << > "HTTP/1.0 > > 200 > > OK" [\r\n] > > 12:58:19,339 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.readResponseHeaders(HttpState,HttpConnection) > > 12:58:19,339 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.readLine() > > 12:58:19,339 [main] INFO httpclient.wire - << "Set- > > Cookie2: > > JSESSIONID=3p9gsn38l1;Version=1;Discard;Path="/webesa"" [\r\n] > > 12:58:19,339 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.readLine() > > 12:58:19,339 [main] INFO httpclient.wire - << "Set- > > Cookie: > > JSESSIONID=3p9gsn38l1;Path=/webesa" [\r\n] > > 12:58:19,339 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.readLine() > > 12:58:19,339 [main] INFO httpclient.wire - << > > "Servlet-Engine: Tomcat Web Server/3.2.3 (JSP 1.1; Servlet 2.2; Java > > 1.3.1_04; Windows 2000 5.0 x86; java.vendor=Sun Microsystems Inc.)" > [\r\n] > > 12:58:19,339 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.readLine() > > 12:58:19,339 [main] DEBUG httpclient.Cookie - > > Cookie.parse(): > > Adding cookie - JSESSIONID=3p9gsn38l1; $Path=/webesa > > 12:58:19,339 [main] DEBUG methods.GetMethod - > > GetMethod.readResponseBody(HttpState,HttpConnection) > > 12:58:19,339 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.readResponseBody(HttpState,HttpConnection) > > 12:58:19,339 [main] INFO httpclient.wire - << > "something > > to > > return for the test" > > 12:58:19,339 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.execute(): closing connection since we're using > HTTP/1.0 > > 12:58:19,339 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.close() > > 12:58:19,339 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.closeSocketAndStreams() > > 12:58:19,349 [main] DEBUG httpclient.HttpClient - > > HttpClient.startSession(String,int,boolean): Host:localhost Port:8080 > > HTTPS:false > > 12:58:19,349 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.HttpConnection > > 12:58:19,349 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.open() > > 12:58:19,359 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.execute(HttpState,HttpConnection) > > 12:58:19,359 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.execute(): looping. > > 12:58:19,359 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.writeRequest(HttpState,HttpConnection) > > 12:58:19,359 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.writeRequestLine(HttpState,HttpConnection) > > 12:58:19,359 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.write(byte[]) > > 12:58:19,359 [main] INFO httpclient.wire - >> "GET > > /webesa/ServletRedirector?Cactus_Service=GET_RESULTS HTTP/1.1 > > " > > 12:58:19,359 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.writeRequestHeaders(HttpState,HttpConnection) > > 12:58:19,359 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.write(byte[]) > > 12:58:19,359 [main] INFO httpclient.wire - >> > > "Content-type: application/x-www-form-urlencoded > > " > > 12:58:19,359 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.write(byte[]) > > 12:58:19,359 [main] INFO httpclient.wire - >> "Host: > > localhost > > " > > 12:58:19,359 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.write(byte[]) > > 12:58:19,359 [main] INFO httpclient.wire - >> "User- > > Agent: > > Jakarta HTTP Client/2.0.0a1 > > " > > 12:58:19,359 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.writeLine() > > 12:58:19,359 [main] INFO httpclient.wire - >> \r\n > > 12:58:19,359 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.readResponse(HttpState,HttpConnection) > > 12:58:19,359 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.readStatusLine(HttpState,HttpConnection) > > 12:58:19,359 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.readLine() > > 12:58:19,369 [main] INFO httpclient.wire - << > "HTTP/1.0 > > 200 > > OK" [\r\n] > > 12:58:19,369 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.readResponseHeaders(HttpState,HttpConnection) > > 12:58:19,369 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.readLine() > > 12:58:19,379 [main] INFO httpclient.wire - << > > "Servlet-Engine: Tomcat Web Server/3.2.3 (JSP 1.1; Servlet 2.2; Java > > 1.3.1_04; Windows 2000 5.0 x86; java.vendor=Sun Microsystems Inc.)" > [\r\n] > > 12:58:19,379 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.readLine() > > 12:58:19,379 [main] DEBUG methods.GetMethod - > > GetMethod.readResponseBody(HttpState,HttpConnection) > > 12:58:19,379 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.readResponseBody(HttpState,HttpConnection) > > 12:58:19,379 [main] INFO httpclient.wire - << > > "<webresult></webresult>" > > 12:58:19,379 [main] DEBUG httpclient.HttpMethod - > > HttpMethodBase.execute(): closing connection since we're using > HTTP/1.0 > > 12:58:19,379 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.close() > > 12:58:19,379 [main] DEBUG httpclient.HttpConnection - > > HttpConnection.closeSocketAndStreams() > > 12:58:19,429 [main] DEBUG n.TestServletTestCase_HttpUnit - Exception > in > > test > > junit.framework.AssertionFailedError: expected:<something to return > for > > the > > test> but was:<> > > at junit.framework.Assert.fail(Assert.java:51) > > at junit.framework.Assert.failNotEquals(Assert.java:234) > > at junit.framework.Assert.assertEquals(Assert.java:68) > > at junit.framework.Assert.assertEquals(Assert.java:75) > > at > > > com.xxx.xxx.test.app.gen.TestServletTestCase_HttpUnit.endHttpUnitGetText > (U > > nk > > nown Source) > > at java.lang.reflect.Method.invoke(Native Method) > > at > > > org.apache.cactus.AbstractWebTestCase.callEndMethod(AbstractWebTestCase. > ja > > va > > :177) > > at > > > org.apache.cactus.AbstractWebTestCase.runGenericTest(AbstractWebTestCase > .j > > av > > a:263) > > at > > org.apache.cactus.ServletTestCase.runTest(ServletTestCase.java:133) > > at > > org.apache.cactus.AbstractTestCase.runBare(AbstractTestCase.java:195) > > at junit.framework.TestResult$1.protect(TestResult.java:106) > > at junit.framework.TestResult.runProtected(TestResult.java:124) > > at junit.framework.TestResult.run(TestResult.java:109) > > at junit.framework.TestCase.run(TestCase.java:131) > > at junit.framework.TestSuite.runTest(TestSuite.java:173) > > at junit.framework.TestSuite.run(TestSuite.java:168) > > at > > > org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTe > st > > Ru > > nner.java:325) > > at > > > org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitT > es > > tR > > unner.java:524) > > > > -----Ursprungliche Nachricht----- > > Von: Vincent Massol [mailto:[EMAIL PROTECTED]] > > Gesendet: Montag, 26. August 2002 12:15 > > An: 'Cactus Users List' > > Cc: 'Oliver Rossmueller' > > Betreff: RE: JUnitEE and Cactus > > > > > > Hi Oliver, > > > > > -----Original Message----- > > > From: Oliver Rossmueller [mailto:[EMAIL PROTECTED]] > > > Sent: 25 August 2002 15:50 > > > To: Vincent Massol > > > Subject: JUnitEE and Cactus > > > > > > Hi Vincent, > > > > > > finally I could find some time to check out the latest release of > > > Cactus, so here are from my point of view the advantages and > > > disadvantages of JUnitEE and Cactus: > > > > > > > > > Advantages of JUnitEE > > > > > > - no special requirements to test case classes - > > > junit.framework.TestCase as superclass is enough > > > > ok. The only reason for having to extend a given test class (on the > > server side) is to easily pass the servlet objects (request, response, > > etc) to the test. How is this done by JUnitEE? By calling some static > > class? The TestCase could also be wrapped but then the user will have > to > > perform a cast to access the additional features. > > > > > - as simple as possible: write your tests, package them in a WAR > with > > > JUnit and JUnitEE, deploy the WAR and start your tests from your > > browser > > > > Actually this is also exactly the lifecycle with Cactus if you want to > > test from your browser. If you want to test with your IDE, Ant, etc, > > simply use *any* existing test runner (including JUnitEE ! :-))and off > > you go. > > > > > > > > Disadvantages of JUnitEE > > > > > > - requires special Ant task which does the client/server > communication > > > > Does JUnitEE already provides this? It didn't last time I looked. If > it > > now does, then Cactus and JUnitEE are now really the same, as this is > > what is done in Cactus :-). Another reason to merge ... :) > > > > > > > > > > > Advantages of Cactus > > > > > > - no special Ant integration is necessary as the junit task will > also > > > run Cactus test cases (the client/server communication is > encapsulated > > > in the test case itself) > > > > yep > > > > > - testing of servlet output is easy because of httpunit integration > > > > yep > > > > > > > > Disadvantages of Cactus > > > > > > - configuration of client-side cactus.properties > > > > yes and no. cactus.properties is optional. However, you still need to > > tell Cactus what URL it should call to find its redirector (that's the > > only piece of information that is required). Note that this is not > > needed if you're running your test from a browser. > > > > > - requires special test case super class > > > > yep. Not sure this is really a problem though. Do you have an issue in > > mind ? > > > > > - servlet test runner produces xml which is displayed in a useful > > manner > > > in IE only; for other browsers a transformation to html would be > > > required but would also require xerces/xalan in the WAR > > > > yes, you're right. I would be +1 to offer an HTMLFormatter class in > > addition to the XMLFormatter one that exist for users who do not use a > > browser that can display XML *and* that cannot do XSLT transformation. > > That's one of the things JUnitEE could bring should we agree to merge > > ... :-) > > > > > > > > > > > I was thinking about how to integrate the two projects. The most > > > important aspect of JUnitEE is it's simplicity and ability to run > test > > > cases of any kind inside the servlet container. > > > > Can you write taglib tests with JUnitEE? Can you write Filter tests > too? > > > > > To get the same out of > > > Cactus would mean to remove client/server communication from the > test > > > case. > > > > Not true :-) Cactus already provides this. The tomcat integration > > tutorial (http://jakarta.apache.org/cactus/howto_tomcat.html) shows > that > > you don't have to care about the client/server communication at all. > > > > > This is a big change of Cactus' architecture and would require a > > > complete rework and would probably break existing Cactus-based test > > > cases. So I don't think you would like to go this way. > > > > I don't understand. Can you please give me more details? > > > > > > > > The only realistic way in cooperation that would make sense for me > is > > > for you to use JUnitEE as the servlet test runner instead of writing > > > your own one. So you could benefit from the development of JUnitEE > and > > > concentrate on the core features of Cactus. For example I could > extend > > > JUnitEE to produce xml output as your test runner does. I was > already > > > thinking about using xml for the communication with the ant task, so > I > > > might do it anyway. > > > > > > > Ok. Here is my point of view: > > > > - I think this niche of in-container unit testing is too small for > > having 2 projects > > - You mentioned an Ant taks for JUnitEE to communicate with the server > > side. This is exactly the same as Cactus. This means that JUnitEE and > > Cactus become competitors (they are on the same domain). > > - I believe it is *way* better to join our forces and make something > > better for our users than each separate project. You are working alone > > on JUnitEE and I am working almost alone on Cactus. Let's join forces! > > There are still lots of things to do to improve integration unit > testing > > : > > - EJB redirectors including MDB redirector for unit testing MDBs > > - Bundling Cactus/JUnitEE with application server containers to > make > > them a de facto standard. > > - Write IDE plugins to make it even easier. I have started a Maven > > plugin for Cactus and I am currently learning plugin development in > > Eclipse in order to write a Cactus plugin > > > > > You mentioned some plugins you would like to create for Cactus. > Could > > > you be a little bit more specific in this point and also in what > your > > > plans for Cactus are? > > > > See above. You can also get some ideas by looking at the todo list : > > http://jakarta.apache.org/cactus/howto_tomcat.html > > > > In addition, there may be another new area of testing that could be > > interesting (that's for more longer term) : "Stress Unit Testing" (TM) > > :-) > > > > Persons who write server side applications are usually writing them to > > support heavy loads and would be very interested to know how some > > specific methods handle the load (and test thread handling). Ok, there > > are lots of issues to discuss and I'm not even sure it could work but > > that's an idea. > > > > Moreover there are persons who have started extensions to Cactus for > > providing even further ease of testing for specific frameworks. An > > example is the StrutsTestCase project for unit testing Struts actions. > > > > I am also currently integration Jetty completely into Cactus as a > Cactus > > extension. You may know that Jetty is a very fast embeddable servlet > > engine. It is working on my machine (I haven't committed it yet) and > the > > net result is that I can now start servlet/filter/JSP tests without > > having to create a WAR and deploying it! Ok, it won't fit all > scenarios > > but it is a *very* fast way to unit test your code in a container! > Jetty > > starts in 350 ms ! Here is how you can use it: > > > > <junit> > > <classpath> > > cactus > > jetty jar > > </classpath> > > > > my tests > > </junit> > > > > That's the minimum you need! Nothing more, no config files, etc. > > > > I would view this method as very useful when you're inside your IDE > and > > writing your code. As soon as you have finished one method, you right > > click on your test and use the IDE JUnit integration and click "run" > and > > it starts in 350 ms and run your test. Wow! Then as a second step you > > would automate running the tests in Ant for example using your real > > container, and you would run these tests less often (for example every > > few hours or once very day). > > > > > I have also some points on my list for the next > > > release of JUnitEE: > > > > > > - allow to run a single test out of a test suite; this is very > helpful > > > for debugging and is the most important feature I'm missing in > JUnitEE > > > at the moment > > > > yes. Good idea :-) > > > > > - create a servlet/jsp which displays all test suites and tests > > > available so you can select the suites and tests you would like to > run > > > in the browser in a user-friendly way > > > > another good idea ... > > > > > - flush mode of the test runner so you get immediate feedback while > > the > > > tests are running and don't have to wait until all tests are > finished > > to > > > see the results > > > > yes that would be nice ... > > > > > > > > That's it for the moment. Perhaps when I know more about your plans > > and > > > ideas we will find other possibilities to cooperate, at the moment I > > can > > > only see the way mentioned above. > > > > > > > Oliver, I really think we should merge and bring all these wonderful > > ideas together. > > > > Tell me what you think > > > > Thanks > > -Vincent > > > > > Greetings > > > Oliver > > > > > > > > > Vincent Massol wrote: > > > > > > >Hi Oliver, > > > > > > > >Good to see that someone as taken the lead on JUnitEE! I am working > > on > > > >Cactus and in version 1.4, Cactus has added a ServletTestRunner in > > > >addition to supporting all the existing JUnit Test Runner. > > > > > > > >I have to say that although Cactus has a strong community of users, > I > > am > > > >the only person really leading the Cactus project and I'm really > > looking > > > >for synergies/help/partners/etc. > > > > > > > >I think Cactus and JunitEE are doing very very similar things now > and > > > >that Cactus is now as easy to use as JUnitEE (If not, that's one > > subject > > > >we could work on! :-)). I would be very happy to integrate any > > JUnitEE > > > >feature that you would like to bring ... ;-) > > > > > > > >I think, this domain of integration unit testing is very small and > we > > > >could benefit from mutual help. There are still nice things to do > ... > > > >like the EJB Redirector stuff ... > > > > > > > >Would you be open to discuss this ? > > > > > > > >Thanks a lot > > > >-Vincent > > > > > > > > > > > > > > > >>-----Original Message----- > > > >>From: [EMAIL PROTECTED] > [mailto:junitee-user- > > > >>[EMAIL PROTECTED]] On Behalf Of Oliver Rossmueller > > > >>Sent: 15 August 2002 21:59 > > > >>To: [EMAIL PROTECTED] > > > >>Subject: [junitee-user] Release 1.4 > > > >> > > > >>Release 1.4 of JUnitEE is available for download at > > > >>http://sourceforge.net/project/showfiles.php?group_id=31476 > > > >> > > > >>Changes: > > > >>------------ > > > >>- New option to run all tests found in a specified jar file > > > >>- Ant task for build integration > > > >>- TestServletBase is no longer abstract and should work as is > > > >>- Bug Fixes (Bug 583856, 583859) > > > >> > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
