Better comparison of Java implementations

This post is history. Read the latest version.

 

I already posted a class to enable the comparison of Java method implementations. However, this was a draft method rather than a true solution.

Today, I come back with a(n almost) valid solution. You can get it on my Github repository: labs-java, implementation-comparer branch.

Basically, it will be able to compare several implementations of any class within its context, rather than the previous solution which forced you to rewrite the methods within the comparer.

Let us imagine you have a Foo class with a bar(String arg), but you suspect this method can be written in a better and more efficient way, but you want to ensure both methods return the same results and make sure which methods is the most efficient.

You will have to write the variants for your method, and suffix them with an incremental index (bar1(String arg), bar2(String arg), …). Then, you will call the implementation comparer with some arguments you wish to test:

This will output something like this:

The time checks are performed only if the info log level is above INFO, and the result comparison displays the details only on debug level, but the compare method returns true if all methods return the same result, and false otherwise.

This comparer can be really useful when you are refactoring or even included in unit testing if you find a use for it.

For more details, you can have a look at the class itself. It is really not that complicated and I made it an obligation to have documented code nonetheless.

As a reminder, you can also have a look at my my previous draft version, which came with more explanations. The main principle remains the same, only with more freedom.

And if you need help, you can always ask below, as I will not go further into details right now.

For the logging of tables, I used Alcibiade’s asciiart library.

All this just in preparation of my next post… And yet, I am quite satisfied with myself and feels this will come in handy next time I refactor…

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:

 And what about SOAP?

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.