Java: Method Chain with Snippet

I've noticed a pattern pop up a few times in my Java code in the past 6 months. Maybe it's a decent pattern, or maybe I only have a hammer.

The problem I'm trying to solve is setting some global state, running a test, and ensuring that the global state is set back to it's original (or correct) value. My usual solution to this problem is to remove global state, but not all global states are created equally. The two global states I've been unsuccessful at removing are the current time and system properties.

In my previous post I described how I freeze time using the Joda library. The example code for freezing time was the first time I used a Method Chain with a Snippet. At the time I thought it was an ugly solution, but the best I could come up with.

A few months later I was testing some code that set and read from the system properties. My first tests set the properties and didn't clean up after themselves. This quickly caused trouble, and I found myself turning to Method Chain with Snippet again.

Here's some example code where I verify that setupDir doesn't overwrite a default property:

    @Test
    public void shouldNotOverrideDir() {
        new Temporarily().setProperty("a.dir", "was.preset").when(new Snippet() {{
            new Main().setupDir();
            assertEquals("was.preset", System.getProperty("a.dir"));
        }});
    }

And, here's the code for the Temporarily class

    public class Temporarily {
        private Map properties = new HashMap();
    
        public void when(Snippet snippet) {
            for (Map.Entry entry : properties.entrySet()) {
                System.setProperty(entry.getKey(), entry.getValue());
            }
        }
    
        public Temporarily setProperty(String propertyName, String propertyValue) {
            if (System.getProperty(propertyName) != null) {
                properties.put(propertyName, System.getProperty(propertyName));
            }
            System.setProperty(propertyName, propertyValue);
            return this;
        }
    }

The code works by setting the desired state for the test, chaining the state cleanup method, and passing the test code as a Snippet to the state cleanup method. The code exploits the fact that Java will execute the first method, then the argument to the chained method, then the chained method.

For the previous example, the 'setProperty' method is executed, then the Snippet is constructed and the initializer is immediately executed, then the 'when' method is executed. The Snippet argument isn't used within the when method; therefore, no state needs to be captured in the Snippet's initializer.

This pattern seems to work well whenever you need to set some state before and after a test runs. However, as I previously mentioned, it's much better if you can simply remove the state dependency from your test.

Freezing Joda Time

Once upon a time Mark Needham wrote about freezing Joda Time. Mark gives all the important details for freezing time (which is often helpful for testing), but I came up with some additional code that I like to add on top of his example.

Two things bother me about Mark's example. First of all, I always like the last line of my test to be the assertion. It's not a law, but it is a guideline I like to follow. Secondly, I don't like having to remember that I need to reset the time back to following the system clock.

I came up with the following idea. It's definitely a poor man's closure, but it does the job for me.

    
    @Test
    public void shouldFreezeTime() {
        Freeze.timeAt("2008-09-04").thawAfter(new Snippet() {{
            assertEquals(new DateTime(2008, 9, 4, 1, 0, 0, 0), new DateTime());
        }});
    }

The Freeze class is very simple:

    public class Freeze {

        public static Freeze timeAt(String dateTimeString) {
            DateTimeUtils.setCurrentMillisFixed(JodaDateTime.create(dateTimeString).getMillis());
            return new Freeze();
        }

        public void thawAfter(Snippet snippet) {
            DateTimeUtils.setCurrentMillisSystem();
        }
    }

The Snippet class is even more simple:

    public class Snippet {}

Using this code I can keep my assertions as close to the end of the test method as possible, and it's not possible to forget to reset the time back to the system clock.

Developer Testing: Welcome to the Beta Test

In March of 2009 I gave a talk at SpeakerConf about developer testing. The presentation is available as 'desktop' and 'iPhone' m4v files.

• speakerconf2009.m4v ('desktop')
• speakerconf2009iPhone.m4v ('iPhone')

Unfortunately, the Q&A session is inaudible, so I cut the end short.

Mockito non-hamcrest any matcher

These days I'm using Mockito for my behavior based tests. I like Mockito's integration with Hamcrest, but I don't always like the viral matcher requirement. In particular, if I have a method that takes 3 arguments, I don't like the fact that if I use a matcher for one argument I have to use a matcher for all 3. For example, in the following verification I don't care about the callback instance, but I do care about the timeout and the async flag.

verify(channel).subscribe(any(Callback.class), eq(100), eq(true))

I was toying with some code the other day and it occurred to me that I should be able to write my own any method that achieves what I'm looking for without requiring my other arguments to be matchers.

The code below is what I've started using as an alternative.

    public static  T any(final Class clazz) {
        MethodInterceptor advice = new MethodInterceptor() {
            public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
                if (method.getName().equals("equals")) {
                    return clazz.isInstance(obj);
                }
                return null;
            }
        };

        return new ProxyCreator().imposterise(advice, clazz);
    }

Using my any implementation the first example code can be written like the example below.

verify(channel).subscribe(any(Callback.class), 100, true)

My implementation relies on classes from cglib and spruice; however, you could copy the necessary class from spruice very easily. Here are the referenced classes:

• net.sf.cglib.proxy.MethodInterceptor
• net.sf.cglib.proxy.MethodProxy
• org.spruice.proxy.ProxyCreator

There may be limitations of this implemenation, but it's been working fine for me. Please let me know if you spot a potential improvement.

Calling Clojure from Java

Calling Clojure from Java is easy, if you know which classes are important.

On my current project I make all my Clojure files resources, load them, and call the functions directly. The following example shows Clojure printing the argument it's given.

; printer.clj
(ns printer)

(defn print-string [arg]
  (println arg))

// Java calling code
RT.loadResourceScript("printer.clj");
RT.var("printer", "print-string").invoke("hello world");

There's a few things worth noting about the example: RT.var takes the namespace name and the function name. The Var returned by RT.var has an invoke method that allows you to pass any number of Objects. The invoke method also returns an Object, which allows you return values from Clojure where necessary.

It's also worth noting that the Clojure/Java interop is very, very good. You could pass a Java object to Clojure, make changes to it in Clojure, and return it back to Java. Of course, you might not even need to return it to Java since the instance referenced in Clojure would be the same instance referenced in Java.