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]>
