Tuesday, March 20, 2012


It's been a little while since my last post; I've been very busy professionally and personally.

For example, over the last month, I've weighed EasyMock and Mockito, then chosen the latter and cranked out a first draft of tests to cover a business logic layer already written.

This last week or so, however, I’ve been playing around with REST-assured in my spare time in an effort to leave no stone unturned on the way to covering every path in our restlet with a test. This is a very lightweight, open-source (Google-hosted) framework that allows you to test your JAX-RS implementation.

ReST testing is brittle

This sort of testing is a little brittle to say the least. It requires...

— Tomcat running the restlet.
— a database (in my case anyway) initialized with at least a modicum of test fodder.

In my case, I targeted one entity in my server that amounts to a collection of 172 guaranteed objects in my database. So, ...

— in order to test the HTTP POST, PUT and DELETE verbs, assumptions had to be made as to the existence of objects (being able to add rows to the database, some to update and some to delete for completeness).

The result is or can be somewhat destructive.

That's three strikes and the first two clearly mean this is not unit testing anyway, but something else (although, you code in JUnit).

I'm in the REST-assured community trying to find out how to solve the third problem. Still, it's a back-burner project as it's not super important and there aren't a tremendous number of code paths involved. These paths may turn out to be the 20% I don't cover.

But wait: There are advantages!

Still, it's pretty cool: the code reads wells, is simple and very self-documenting.

Second, it is a great formalism for stating exactly what URIs are implemented (handled by my ReSTful service) and how they should behave.

Last, it covers creating failure situations and explicit checking for particular HTTP status code returns.


These last two points scratch (nay, gash deeply with long nails!) my TDD fascination and are the real reason I even walked this path.

Check out my notes and sample code here.