## Unit-testing a REST-client Spring bean

I guess a bit of context is required here: I had to implement a Spring bean which should be able to call a distant REST service, with high availability constraints. One of them was that even if distant service was down, the bean should return a result and not an Exception.

Of course, I wanted to ensure my bean behaved the right way, no matter what future evolutions would bring. Unit-testing then. Since it is a Spring bean, using Spring test. But then an awful question: how do I simulate a call to a distant servlet in a Sprint test context?

# The REST-client bean

Something very basic, using Apache’s httpclient to retrieve a stream. See the example:

Here the Maven dependency for httpclient:

And finally the bean initialization in the Spring application context:

# From the real thing to the unit-tests

Of course, since the URL is set in the Spring context, it easy to map to another one in the test context. Yet, I must have something listening to the test URL.

Something inside my test context, since I do not want to depend onto another server. Using Spring remoting? Start an embedded Jetty? Those seemed possible, but uselessly complicated.

For the first time, I asked for Stackoverflow’s help, and it came to me with the hints I needed to google out the pieces I was missing.

# Unit-testing using a light embedded application server

I was recommended to use javax.xml.ws.Endpoint with a JAX-RS annotated-class. The second part was what I aimed at from the beginning, using Jersey. However, Endpointquickly proved designed for use with SOAP services, not REST.

I kept searching for something similar and found an example of how to use Jersey classes with a Grizzly embedded server. It is acutally dead simple.

## Write a fake REST service

There are a-many tutorials about Jersey, I will let you find the one fit for you if need be.

Here is my fake service, yet. As I wanted to test the behaviour of my bean with several HTTP error status codes (401 if my request is incorrect, 404 if the distant service is down, 500 if I break it down, …), I decided that the passed parameter would be parsed to cause this status code if beginning with 10, 20, 30, 40 or 50. If it is any use to you, you are welcome to copy it (though it is quite basic, but quite enough for my unit-tests).

## Publish to a server

How difficult can it be to write a server? Very little, actually, if you know which server to call. I chose Grizzly. See below.

As for publication to the server, the highlighted line does most of the work.

## Start the server in the Spring context

Basically, all you have to do is to is set the bean with a URL and call the start() method. Translated for your context, it looks like the following:

## Almost done!

Now, when your Spring test context starts, a Grizzly server is started and listens on http://127.0.0.1:8088

Plus, a webservice is deployed onto it. The Path annotation tells us it will be made available at http://127.0.0.1:8088/hello

OK, so we just have to initialize our to-be-tested REST-client bean with the correct URL for the service:

You’re good to go and test all the cases you want to!

## Which dependencies should I use?

Right, I almost forgot I myself had some troubles figuring out which dependencies to use…

You might want to declare some repositories too:

Well, for SOAP, you can apply quite alike-looking practices, using javax.xml.ws.Endpoint instead of a Grizzly server, and the J2EE JAX-WS annotations instead of Jersey.