JUnit testing services and clients with javax.xml.ws.Endpoint

Following situation: you have written some generic stub to use in your projects that creates a client for a service. Your client is smart and does some magic for connections (proxy, cache or other kind of magic). Or maybe you just have written a service for that matter. Anyway, you now want to test it. Unit testing the functionality of your methods is a must. But you still want to reach 100% coverage and need to test the service as it would run in real life.

Then you can use the javax.xml.ws.Endpoint class.

If you prefer figuring it out yourself, you can find the code (as a project for netbeans) --here--

To follow the code examples as html click  --here--

So here is how you do it:

If you've coded nothing fancy, then you probably have a class like this:

This is a generic client for opening connections to services. It gives you back a port of the type of your service where you can call your operation as a method of the port. It is very convenient if you have to do some nasty network-connection-recovery-proxy-cache thing, then you just do it once and put it into a library. 

Anyway, now you want to test this class, as is central to all your service calls, you want it to bee 100% fool proof.  You probably already notice where the problem is going to be: Yes there is a static call to javax.xml.ws.Service. Unless you are using PowerMockito or something like that, stubbing static classes is going to be a problem. Furthermore, why making a mock? Although I am a real fan of mocking, in this case I'd rather test the client for real. 

The Idea: the plan here is to create a test service (as simple as possible), start it up before every Unit-Test, create the connection and have the service do what I need for the test. 

So it breaks down into 3 Steps:

Step 1- Create a Web Service

Create a test service, with javax.jws it has become very easy to do so by using annotations. Put it into your Test-Packages, so it does not get mixed up with productive code. This is an echo service which gives you back whatever you put in.

Step 2 - Create a Service Interface

This is the fancy part of your client implementation. By creating Service-Interfaces you can use generics to use the same code for creating clients and cast it to the Service you are using.

Step 3 - Test It

In your test class, make a setup and a tearDown method. Use the annotation @Before ans @After respectively.
In your setup method, now you can create a service using the javax.xml.ws.Endpoint class and publish your service implementation. This will create and start an embedded jetty server and publish your service. Don't forget to tear it down afterwards, or the next test won't work because the port is busy. Oh, and think of a port number that is not used in your CI or DEV environment. (By the way, is there any convention to ports you can use for unit testing?)

And there you have it!

You will now be able to use the service in your unit tests. To test exception handling, you could for example pass parameters to your service and have it throw the exceptions. 

Disclaimer

This is not new, I found lots of comprehensive articles about this, the best one form Glen Mazza's Weblog, to which I definitely refer, if you need any other server functionality that is not provided by embedded jetty. I would see any test needing some special tomcat functionality (or from other application servers for that matter) very close to the border to integration tests. But what is a unit test anyway, huh? And 100% are 100%, so if you think it is worth it, you'll need to create a war and deploy it to be able to use it.