Here I was, merrily testing my way through a piece of software that sends emails. According to the Java Mail documentation, you are supposed to first create an email session as follows:

Session mailSession = Session.getInstance(properties);

(it is worth noting that all what the getInstance() method does is call the private constructor for Session: new Session(props, null)).
Had Session been a more normal class, I could have mocked it like that:

Session mockSession = mock(Session.class);

and probably checked how it is being passed around like this:

verify(someService).startEmailSession(mockSession);

What follows is what I have to do instead.

The case of static methods

If getInstance() had been an instance method, I would have been able to mock it:

Session mockSessionProvider = mock(Session.class);
Session mockSessionInstance = mock(Session.class);
when(mockSessionProvider.getInstance()).thenReturn(mockSessionInstance);

Unfortunately, a static method cannot easily be mocked with Mockito (other mocking frameworks support that, but I believe they make the tests too obscure). So, first step: create a wrapper class just for the builder method.

public class SessionProvider {
	public Session getInstance(Properties properties) {
		return Session.getInstance(properties);
	}
}

The case of final classes

So far, so (relatively) good. However, since Session is a final class, the usual mocking mecanism under Mockito does not work:

SessionProvider mockSessionProvider = mock(SessionProvider.class);
Session mockSessionInstance = mock(Session.class); // fails because Session is final
when(mockSessionProvider.getInstance()).thenReturn(mockSessionInstance);

The case of private constructors

Another option would have been to instantiate the session instance, but that fails too, since the constructor is private:

SessionProvider mockSessionProvider = mock(SessionProvider.class);
Session sessionInstance = new Session(properties, null); // fails because constructor is private
when(mockSessionProvider.getInstance()).thenReturn(sessionInstance);

A third way might have been to call the original Session.getInstance() to create the test object:

SessionProvider mockSessionProvider = mock(SessionProvider.class);
Session sessionInstance = Session.getInstance(properties);
when(mockSessionProvider.getInstance()).thenReturn(sessionInstance);

That would work, but that also opens a whole new can of worms. Session does not implement the equals() method, so if I want to check the value of the Session instance passed around, I must either:

• compare with the pointer to the sessionInstance — the issue is that there is no way to check that the session has not been changed (any call to a setter method on the session instance will have no effect on the comparison of pointers)
• implement a generic deep equal matcher for Mockito — something we did at my company, but that I am reluctant to do myself
• use an argument captor to catch the instance passed and test — which produces a fair amount of awkward lines of test
• create a custom argument matcher — which hides the comparison in a separate class or method
• yet another is to wrap the instance of Session in yet another class, such as SessionInstance — which would require us to also wrap any service that takes an instance of Session

So we also need a wrapper for the Session instance:

public class SessionInstance {
	private final Session session;

	public SessionInstance(Session session) {
		this.session = session;
	}

	public Session getSession() {
		return session;
	}
}

Which forces us to change the SessionProvider:

public class SessionProvider {
	public SessionInstance getInstance(Properties properties) {
		return new SessionInstance(Session.getInstance(properties));
	}
}

At last, we can mock this way:

SessionProvider mockSessionProvider = mock(SessionProvider.class);
SessionInstance mockSessionInstance = mock(SessionInstance.class);
when(mockSessionProvider.getInstance()).thenReturn(mockSessionInstance);

Done? Hardly. All other, possibly mockable, classes from third-parties that rely on instances of Session must now also by wrapper. For example, a third-party JavaMailTransport that requires an instance of Session now needs its own wrapper if I want to test it. Sigh…

A reminder on how varargs work: essentially, they allow the last parameter of a method to be made of zero to many values of the same type.
For example, a method like this:

int max(int... values) {...};

is used by code like that:

int maximum = max(1, 2, 7, 0);
int maximum = max(1);

In truth, that form is only moderately useful in production code. It turns out that, on my projects at least, it is not so common for methods to be called with varying number of parameters. And in those cases, it is often acceptable to simply overload a method with more parameters.

There are however at least two cases where varargs shine.

One is in utilities classes. For example, Math.max() only takes exactly two parameters. Which comparisons between 3 or more elements very awkward. If a varargs had been used, Math.max(3, Math.max(1, 4)) would be written Math.max(3, 1, 4). Agreed, that does not happen that often. But it does occasionally.
(I must admit that I do not understand exactly why Math.max() has not been modified to take a varargs nowadays)

However, the biggest benefit, I believe, is in the writing of tests.
Tests tend to contain lots of variations in the values passed to the code under test. And it is critical to keep the clutter to a minimum.
For example, here is how a typical series of tests might look like

@Test
public void should_find_the_longest_name_for_a_single_user() {
	List users = new ArrayList();
	users.add(new User("eric"));
	assertThat(findLongestName(users), is("eric"));
}

@Test
public void should_find_the_longest_name_when_shorted_is_first() {
	List users = new ArrayList();
	users.add(new User("eric"));
	users.add(new User("cecile"));
	assertThat(findLongestName(users), is("cecile"));
}

@Test
public void should_find_the_longest_name_when_longest_is_first() {
	List users = new ArrayList();
	users.add(new User("cecile"));
	users.add(new User("eric"));
	assertThat(findLongestName(users), is("cecile"));
}

@Test(expected = RuntimeException.class)
public void should_fail_when_search_for_the_longest_name_with_no_users() {
	assertThat(findLongestName(new ArrayList()), is("eric"));
}

Of course, they can be made a bit nicer using the varargs in Arrays.asList():

@Test
public void should_find_the_longest_name_for_a_single_user() {
	assertThat(findLongestName(asList(new User("eric"))), is("eric"));
}

@Test
public void should_find_the_longest_name_when_shorted_is_first() {
	assertThat(findLongestName(asList(new User("eric"),
		new User("cecile"))), is("cecile"));
}

@Test
public void should_find_the_longest_name_when_longest_is_first() {
	assertThat(findLongestName(asList(new User("cecile"),
		new User("eric"))), is("cecile"));
}

@Test(expected = RuntimeException.class)
public void should_fail_when_search_for_the_longest_name_with_no_users() {
	findLongestName(Arrays.asList());
}

However, the real goodness comes when writing our own builder method:

private static List users(String... names) {
	List users = new ArrayList();
	for (String name : names) {
		users.add(new User(name));
	}
	return users;
}

(side note: I like this type of methods to be private -so that I get notified when they are not used anymore- and static -mostly because they look nicer in italic, which makes it clearer that they are not part of the code being tested-)

which allow our tests to become:

@Test
public void should_find_the_longest_name_for_a_single_user() {
	assertThat(findLongestName(users("eric")), is("eric"));
}

@Test
public void should_find_the_longest_name_when_shorted_is_first() {
	assertThat(findLongestName(users("eric", "cecile")), is("cecile"));
}

@Test
public void should_find_the_longest_name_when_longest_is_first() {
	assertThat(findLongestName(users("cecile", "eric")), is("cecile"));
}

@Test(expected = RuntimeException.class)
public void should_fail_when_search_for_the_longest_name_with_no_users() {
	findLongestName(users());
}

Tests become a lot shorter, consistent, and easier to read. In fact, at this point, it is worth grouping the tests (at least those that do not throw an exception) into a single one:

@Test
public void should_find_the_longest_name_for_a_single_user() {
	assertThat(findLongestName(users("eric")), is("eric"));
	assertThat(findLongestName(users("eric", "cecile")), is("cecile"));
	assertThat(findLongestName(users("cecile", "eric")), is("cecile"));
}

@Test(expected = RuntimeException.class)
public void should_fail_when_search_for_the_longest_name_with_no_users() {
	findLongestName(users());
}

Final note: I prefer not to group those builder methods into a general utilities class — I tend to duplicate them in each test class. One reason is that I prefer keeping much of the test code close together. Another is that I tend to change the name of the method from test class to test class to make the code more fluent. Also, I think that DRY principles are not as important in the tests as they are in the production code.

His main point is that, because Clojure is a functional language, functions have no side-effects and therefore can be used directly in the tests.

For example, the production code

(defn update-all [os]
  (update os))

would be tested with something like

(testing "update-all"
  (let [
    o1 (make-object ...)
    o2 (make-object ...)
    os [o1 o2]
    us (update-all os)
    ]
    (is (= (nth us 0) (update o1)))
    (is (= (nth us 1) (update o2)))
    )
  )

There is no reason to believe that the (update) function is side-effect-free

Changing internal values is only one way of creating side-effect. I admit that Clojure encourages coders to write code that does not change variables (if I got it right, it is definitely possible to do so, but with some additional work). However, that effect only stops at the boundaries of the language. At some point, it might access the file system or a database. Clearly, the state might change there.

Correct implementation of the (update-all) function depends on the correct implementation of (update)

Bob Martin says: ”this test simply checks that the appropriate three functions are getting called on each element of the list”.
Suppose that the (update) function does not do anything or maybe does something that does not return a value, such as printing out to the console. Then, calling it will have the same effect as not calling it at all. The test above will pass even if the (update-all) function does not provide any implementation at all. When, later, the bug is found, it will be harder to fix.

The test could be clearer (with a more powerful test framework)

One of my biggest concerns is that the test looks a lot like the code itself. Looks like duplication of information to the reader.
If there was a mock framework for Clojure, I would expect to see something like

(testing "update-all"
  (let [
    pre-conditions (
      (should-return (update 1) 1.5)
      (should-return (update 3) 3.0) )
    o1 (make-object 1)
    o2 (make-object 3)
    os [o1 o2]
    us (update-all os)
    ]
    (is (= (nth us 0) (1.5)
    (is (= (nth us 1) (3.0)
    )
  )

Bob Martin is right to conclude that “Clojure without TDD is just as much a nightmare as Java or Ruby without TDD.”

But he should also make it clearer that it is lacking a mock framework (he does point to Brian Marick’s work on this).

It should be noted that it is possible to get a similar implementation style in Java as in Clojure, though it is significant work. In fact, that’s often how we use it here at Algodeal. That means mostly relying on immutable objects and state-less methods. Immutable collections from Google Collections help a lot, too. Still, we like to use mocks in our tests (too much for some, probably).

In the end, Uncle Bob’s post is another aspect of the (almost) age-old debate described by Martin Fowler: classicists vs. mockists. If you haven’t already, read Fowler’s article, it’s worth it.

Willem and I thought that we had missed some of our goals (especially demonstrating Mockito), but still many people at the closing session mentioned that they enjoyed it :-)

We tried to prepare a bit before diving into the session. However, in practice, it became a bit chaotic, as many participants tried to make their opinion heard. This was very different than when I do that in trainings or even at Valtech. I guess this is because there were quite a few people (~20) and most of them were rather experienced and strong-headed (I guess they wouldn’t be at such a conference otherwise!).

We managed to have a quick retrospective at the end. Here are some of the things we learnt:

I need to experiment a bit more with Coding Dojo for Legacy Code, but I feel that the format is rather good. Next year, we’ll do better!

It turned out very well. Though one or two participants managed to check their emails at some point during the session, most were paying attention at all times.

A couple of things to remember for future dojos:

• In the past, I have usually attented dojos were either everyone was in front of a computer (either coding or co-piloting), or a single pair was coding in front of the others. After watching Dave Nicolette and Ryan Hoegg facilitate a dojo where all got to code in front of the public at Agile 2008, I thought this was a good way to get participants to do their best, plus let others to read code with a watchful eye.
• A participant mentionned that the exercice helped him realize that names for test methods were very important. Yay!
• For first-timers, always start with a very, very simple exercice. We did the dictionary kata (given a collection of words, find all words in a String that are not in the collection). We managed to complete it satisfactorily in 2x 30 minutes.
• We did our best to run through the code Test First, writing the tests with as little prior thinking as possible. That said, one participant suggested that pairs should talk a little before doing so, in order to get the pair to bond better. Sounds like a good suggestion, though it would probably require more time than what we had available.

All in all, I am happy with the outcome. We should include it in our course curriculum.

Considering this was the first time for me, and that we had to do it all in one take (no editing), I am rather happy with the outcome. There are a couple of minor things I forgot to mention (only the interviewer had notes), but all in all, I managed to say almost all I wanted in the 5 minutes I got. Anyway, this was rather high-level; the target audience for TV4IT is mostly CIOs and project managers.

The idea of those tools is to make changes to the source code (Jester) or the bytecode (Jumble), and check if the tests still pass. If they are well written, they should fail when the code is changed. If not, then the code is not covered properly. Ideally, you should only have one test failing; otherwise, it means that you have redundant tests.

Ivan, the creator of Jester, was present, but admitted that he had not even used it in years. After seeing the interest of the participants, he seems willing to give it more time. Hurray!

Check out my notes on the conference wiki.

This year, I have volunteered to help organize registrations, so I get to see every single registration request. It’s interesting: sometimes, you don’t see anyone registering for days (oh my god, is this going to be a turkey?, then 7 people register in a single day. The general pattern, though, is that the number increase more or less regularly.

Also, about one request in six is pure spam.
We should reach the threshold for the maximum number of seats a couple of days before the event.