Glen,
On May 13, 2008, at 6:42 AM, Glen Mazza wrote:
Hello,
I'd like to add JUnit test cases to the Maven version of my "DoubleIt"
web service provider[1]. The types of things I'd like to test are (1)
that an integer fed is actually doubled in the response, (2) not
well-formed SOAP requests are rejected, and (3) non-schema valid SOAP
requests are rejected.
I can think of two main ways of doing this:
1.) Write test cases the standard Maven way, i.e., create a test
folder
that it is sibling of the service/src/main folder and write the test
cases there. That would require having an embedded Tomcat or Jetty
instance that reads the either the WAR file in target (or,
equivalently,
the exploded war also in target), and makes a servlet out of that so
the
test cases can work. I'm not sure if embedded Tomcat/Jetty can handle
this though--most/all of our CXF test cases don't work with WAR-file
hosted web service providers.
This would work. The embedded jetty can pick up a war directory
fairly easily. We have a couple of tests that do this. Take a look
at the BookServerSpring.java class in the systests module. (package:
org.apache.cxf.systest.jaxrs) It would startup the exploded war
easily and allow you to hit it.
That said, with JAX-WS, in your "setup" method you can just call:
Endpoint ep = Endpoint.publish("http://localhost:8080/blah";, myImpl);
and CXF (or Metro) will automatically setup an embedded http server
(jetty for CXF, metro uses the http stuff that is now part of Java6)
that you can then hit. You don't need a war or anything. That may
have some issues with the wsdlLocation annotation on the classes
though. (don't forget to call stop in the tearDown)
I would just use one of the above. It's pretty simple.
The CXF systest stuff goes one further by forking the server into a
separate process instead of running it in-process with the test
client. In general, that's probably overkill for simple unit style
testing. However, it does make sure there is a completely clean
separation between client/server and the only communication is through
the soap messages. No "statics" or anything that can pollute the
results.
Dan
2.) Create a separate "systests" project that doesn't test anything
until the WAR is (manually) deployed on a non-embedded servlet
container--*then* run the tests. CXF also has this type of test--but
I'm unsure how appropriate it would be for the types of tests I'm
thinking of here.
Any suggestions which is best? What have others done for web service
provider testing?
Thanks,
Glen
[1] http://www.jroller.com/gmazza/date/20080417
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
