jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hirsch Richard <richard.hir...@siemens.com>
Subject AW: HTTPUnit Integration
Date Mon, 26 Aug 2002 11:55:26 GMT
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:vmassol@octo.com]
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:richard.hirsch@siemens.com]
> 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:vmassol@octo.com]
> 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:oliver@oross.net]
> > 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: junitee-user-admin@lists.sourceforge.net
[mailto:junitee-user-
> > >>admin@lists.sourceforge.net] On Behalf Of Oliver Rossmueller
> > >>Sent: 15 August 2002 21:59
> > >>To: junitee-user@lists.sourceforge.net
> > >>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:cactus-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:cactus-user-help@jakarta.apache.org>


--
To unsubscribe, e-mail:
<mailto:cactus-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:cactus-user-help@jakarta.apache.org>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message