Just a quick post to introduce the robotooling project; a collection of useful Java tools available for download via the bad.robot.repo. Rather than re-implement the same utility code again and again, I’ve started to collect things under the bad.robot banner. So far, we have…

If Internet Explorer 8 performs a HTTP GET against some resource and receives a mime-type that it wasn’t expecting, it will ask the user to download the resource and save it. Annoyingly for JSON content this means you wont see the JSON ‘in-browser’ like in Firefox and Chrome. If you’re using Jersey, Oracle’s JAX-RS reference implementation, here’s how to make IE8 play nice.

There’s no reason a unit test can’t also be an acceptance test. If you can prove that the unit behaves a certain way and that in production, it will behave in the same way as in your unit test, the intersection should give you enough confidence.

What seems to make things harder to discuss is that its difficult to agree on a common definition for the different types of testing. As a peer-group, we’re usually horrified by the previous paragraph and ask the question “shouldn’t we start up the entire stack in an acceptance test?”. This often leads us to long-running, duplicative and expensive tests in the name of acceptance testing.

Taking inspiration from Cockburn’s Hexagonal Architecture and being more flexible in our technical definitions of acceptance testing however, we can create lightning fast acceptance testing.

It’s easy to avoid manually managing transactions when frameworks like Spring and containers do a good job of hiding all the details. However, it’s often more advantageous to take the controls and manage your own transactions. We seem to shy away from this but its really straight forward and if it means we’re not tied into yet another framework, why wouldn’t we? Aside from just avoiding frameworks though, how does replacing @Transctional with something bespoke really help us?

Moving from a declarative approach to a more imperative one can help us with testing and by virtue; composability. We can move from something which can only be tested using the framework or container (implying an integration or end-to-end style test) to a more focused style (without the need of said frameworks or containers). If we manage things ourselves and are explicit about the transactional boundaries in production code, we can be more lightweight in our tests.

Mostly as a reminder to myself, getting the Java source on your Mac involves the following.

Recruiting for the next guy on your team is hard. At first glance it doesn’t seem to be, we’ve developed techniques like pair tests but as I start to look at it more closely, I’ve started to notice that even the more progressive techniques don’t preclude us from making the same mistakes as the traditional interview.

Let’s take an example from two teams.

Sometimes, we may want to catch an exception, temporarily ignoring it to continue work before rethrowing it when its more appropriate to do so. I recently saw a slight variation of this whereby the developer wanted to (potentially) catch multiple exceptions, perform some processing then throw. However, it left the question that if more than one was caught, which exception should we actually rethrow. We certainly don’t want to loose any information and should really allow the client to catch the exception in a standard way.

This got me thinking about how we should deal with this kind of thing. In the end, I came up with the idea of a collection class to capture the Exceptions and a sub-class of Exception to represent an exception containing other, embedded exceptions. When you’re done collecting exceptions, you can just check and rethrow as a new exception type.

In a previous post, I was going on about how evil logging is. How it’s often confused as a requirement and often badly misused. The upshot of the post was that if you’re going to log stuff, in our case using Log4J, lets be honest about it and test it. We should be able to say upfront what’s important to log, in what situations and at what log level. Sounds like a straight forward case of test first.

Mocking Log4J however can be a real pain. I’ve managed it in the past using Apache’s logging abstraction and configuring it to use Log4J under the covers but in my previous post, I demonstrated a slightly easier way. A helper class called Log4J that we can use to represent the logging system and that we can make assertions against. Pretty cool so far.

My article “Java the language vs Java the platform” (about the new release of JDK7) has been published in this months Java Tech Journal. Click on the image to download the PDF or read the article online.

I’d love to get some feedback, so please feel free to comment here.

Yesterday, I released the 1.1 version of my micro-library tempus-fugit. From the project’s website

The tempus-fugit library is a small collection of classes and interfaces capturing common abstractions useful when writing concurrent and time sensitive code.

It’s now available from the Maven Central repository having had a bad experience with java.net since their migration (and no longer being able to publish, see this post and another if you’re interested).