TL; DR: Fantom is basically a better Java with a very similar syntax, but with lots of little simplifications and some powerful features such as functions.

Let’s say you want to implement FooBarQix.

For those not in the know, FooBarQix is a variant of FizzBuzz using “Foo” in place of “Fizz” and “Bar” in place of “Buzz.” One difference is that “Qix” plays the same role as “Foo” and “Bar” for number 7. Another difference is that digits 3, 5 and 7 also cause the results to contain instances of those words. FooBarQix receives a minor celebrity status in France, in November 2011 as part of a competition related to the upcoming Devoxx conference in Paris.

Here are a sample output (the C-style comments are not part of the output):

1
2
FooFoo
4
BarBar
Foo
QixQix
8
Foo
Bar
11
Foo
Foo // for 13
Qix
FooBarBar // for 15
...
FooQix // for 21
...
FooFooFoo // for 33
...
FooBar // for 51
Bar
BarFoo // for 53
... // up to 100

Obviously, there are many different possible implementations. Here is one in Java:

public class FooBarQix {
	public static void main(String[] args) {
		System.out.println(new FooBarQix().asTextUpTo(100));
	}

	public String asTextUpTo(int topNumber) {
		String str = "";
		for (int i = 1; i < = topNumber; i++) { 			str += toText(i) + "\n"; 		} 		return str; 	} 	public static final String[] TEXT = new String[] { "", "", "", "Foo", "", 			"Bar", "", "Qix", "", "" }; 	public String toText(int number) { 		StringBuffer result = new StringBuffer(); 		addTextForDivisible(number, 3, result); 		addTextForDivisible(number, 5, result); 		addTextForDivisible(number, 7, result); 		addTextForDigits(number, result); 		return result.length() > 0 ? result.toString() : Integer
				.toString(number);
	}

	private void addTextForDivisible(int number, int digit, StringBuffer str) {
		if (number % digit == 0) {
			str.append(TEXT[digit]);
		}
	}

	private void addTextForDigits(int numberToConvert, StringBuffer str) {
		String asString = Integer.toString(numberToConvert);
		for (int i = 0; i < asString.length(); i++) {
			int digit = Integer.parseInt(asString.substring(i, i + 1));
			str.append(TEXT[digit]);
		}
	}
}

I am going to guide you through a refactoring of this from Java to Fantom.

Direct translation into Fantom code

At this stage, there are only minor differences:

• System.out.println() => Env.cur.out().printLine
• ‘=’ => ‘:=’ for field initialization
• void => Void
• String => Str
• int => Int
• new FooBarQix() => FooBarQix()
• new String[] {…} => Str[...]
• .toString() => .toStr()
• StringBuffer => StrBuf
• Integer.toString(number) => number.toStr()
• string.substring(i, i+1) => string[i..i]
• static final => const

Which leads us to the following Fantom class:

public class FooBarQix {
  public static Void main(Str[] args) {
    Env.cur.out(FooBarQix().asTextUpTo(100));
  }

  public Str asTextUpTo(Int topNumber) {
    Str str := "";
    for (Int i := 1; i < = topNumber; i++) {       str += toText(i) + "\n";     }     return str;   }   public const Str[] TEXT := Str["", "", "", "Foo", "",       "Bar", "", "Qix", "", "" ];   public Str toText(Int number) {     StrBuf result := StrBuf();     addTextForDivisible(number, 3, result);     addTextForDivisible(number, 5, result);     addTextForDivisible(number, 7, result);     addTextForDigits(number, result);     return result.size() > 0 ? result.toStr() : number.toStr();
  }

  private Void addTextForDivisible(Int number, Int digit, StrBuf str) {
    if (number % digit == 0) {
      str.add(TEXT[digit]);
    }
  }

  private Void addTextForDigits(Int numberToConvert, StrBuf str) {
    Str asString := numberToConvert.toStr();
    for (Int i := 0; i < asString.size(); i++) {
      Int digit := Int.fromStr(asString[i..i]);
      str.add(TEXT[digit]);
    }
  }
}

A couple of notes:

• Unlike Java, Fantom is a pure object-oriented language, so all Java ints have been converted into normal Fantom objects
• Str[...] might look like a Java-style array, but it is actually an instance of Fantom’s List; a variety of methods is therefore available on its instances
• void is spelled Void in Fantom, and is an actual Class, although it has no methods available

Syntactic sugar

Lots of things are redundant in the Java syntax. Here is how they can be simplified in Fantom.

• Type inference: it is no longer necessary to declare the type of a variable when it is defined with a typed value
• Class and method protection scope defaults to public
• Env.cur.out().printLine is commonly just written echo()
• semi-colons at the end of the lines are optional
• pair of parenthesis on method calls are optional (not on constructor calls, though)
• List offers a convenient API that allows the chaining of calls, making the construction much clearer

Our code now looks like this:

class FooBarQix {
  static Void main(Str[] args) {
    echo(FooBarQix().asTextUpTo(100))
  }

  Str asTextUpTo(Int topNumber) {
    str := ""
    for (i := 1; i < = topNumber; i++) {       str += toText(i) + "\n"     }     return str   }   const Str[] TEXT := Str[,].fill("", 10).set(3, "Foo").set(5, "Bar").set(7, "Qix")   Str toText(Int number) {     result := StrBuf()     addTextForDivisible(number, 3, result)     addTextForDivisible(number, 5, result)     addTextForDivisible(number, 7, result)     addTextForDigits(number, result)     return result.size > 0 ? result.toStr : number.toStr
  }

  private Void addTextForDivisible(Int number, Int digit, StrBuf str) {
    if (number % digit == 0) {
      str.add(TEXT[digit])
    }
  }

  private Void addTextForDigits(Int numberToConvert, StrBuf str) {
    asString := numberToConvert.toStr
    for (Int i := 0; i < asString.size; i++) {
      Int digit := Int.fromStr(asString[i..i])
      str.add(TEXT[digit])
    }
  }
}

Functions as first class objects

One of the main differences with Java is that functions are available to pass around to other methods. This will be possible in Java 8 sometime in 2013. This has been available on the JVM with Fantom since 2005.
One common way of using a function is via the each() and map() methods, available on collections, strings, and others.

We’ll also take this opportunity to replace the list of values by a map. We could have done that in Java as well. However, this construct is a lot more common in a functional language (that is, one where functions are first-class). There is also a nice Map.get() that can take a default value.

class FooBarQix {
  static Void main(Str[] args) {
    echo(FooBarQix().asTextUpTo(100))
  }

  Str asTextUpTo(Int topNumber) {
    return (1..100).map |Int n| { toText(n) }.join("\n")
  }

  const Map TEXT := [3:"Foo", 5:"Bar", 7:"Qix"]

  Str toText(Int number) {
    result := StrBuf()
    addTextForDivisible(number, 3, result)
    addTextForDivisible(number, 5, result)
    addTextForDivisible(number, 7, result)
    addTextForDigits(number, result)

    return result.size > 0 ? result.toStr : number.toStr
  }

  private Void addTextForDivisible(Int number, Int digit, StrBuf str) {
    if (number % digit == 0) {
      str.add(TEXT[digit])
    }
  }

  private Void addTextForDigits(Int numberToConvert, StrBuf str) {
    numberToConvert.toStr.each |c| { str.add(TEXT.get(c.fromDigit, "")) }
  }
}

Completing the work

A couple of things still bother me: the 3, 5, and 7 digits are repeated in two places. The other thing is that we carry around a string buffer, which is not very elegant.

To remove the string buffer, we’ll get each method to return a computed partial string and concatenate the results.

As for the redundant digits, we’ll use the ones already defined in the map of values… and functions will be put to good and make it really easy to transform those values into strings.

As a additional syntactic sugar, we can omit the generic part of a function signature (when passed to map()) and use “it” as a placeholder for the parameter — or even nothing when there are no ambiguities.

Here is the final result:

class FooBarQix {
  static Void main(Str[] args) {
    echo(FooBarQix().asTextUpTo(100))
  }

  Str asTextUpTo(Int topNumber) {
    return (1..100).map { toText(it) }.join("\n")
  }

  const Map TEXT := [3:"Foo", 5:"Bar", 7:"Qix"]

  Str toText(Int number) {
    Str result := addTextForDivisibles(number) + addTextForDigits(number)

    return result.size > 0 ? result : number.toStr
  }

  private Str addTextForDivisibles(Int number) {
    return TEXT.keys.map |Int digit -> Str?| { number % digit == 0 ? TEXT[digit] : "" }.join
  }

  private Str addTextForDigits(Int numberToConvert) {
    return numberToConvert.toStr.chars.map { TEXT.get(it.fromDigit, "") }.join
  }
}

To be sure, it is possible to write Java code that gets close to that. This means using additional libraries such as Guava and using kludges such as inner classes in place of functions. However, this is clearly not natural in Java. Maybe that will change with Java 8.

Final thoughts

This post has not addressed a number of features offered by Fantom, such as portability (Fantom code can be run both on the .NET CLR and on the JVM), mixins, modules (“pods”), and null-safety. However, I hope to have made clear that Fantom is an intriguing language with a pragmatic syntax. This puts the newer kids on the block such as Kotlin and Ceylon really in an interesting light.

On 18 March 2012 16:26, Jen Rhee <thisisjenica@gmail.com> wrote:
Hi Eric,

I came across your site and wanted to share my infographic about Wikipedia and how it’s redefining the way we research. I saw that you had talked about the first wiki developer, Ward Cunningham, which is why I thought you and your readers might find it interesting! Would you be interested in taking a look? Let me know, as I’d love to get your thoughts on it!

Thanks,
Jen R.

I have never heard of that person. I had mentioned Ward Cunningham a couple of times on my blog, although never in relation to wikis. I thought this was a curious email, and decided to ignore it.

One week later, I received another email:

On 25 March 2012 23:39, Jen Rhee <thisisjenica@gmail.com> wrote:
Hi Eric,

I reached out to you last week and wanted to follow up with you again, in case you missed my email or possibly didn’t receive it. I’ve included my original message below:

I came across your site and wanted to share my infographic about Wikipedia and how it’s redefining the way we research. I saw that you had talked about the first wiki developer, Ward Cunningham, which is why I thought you and your readers might find it interesting! Would you be interested in taking a look? Let me know, as I’d love to get your thoughts on it!

Thanks again,
Jen

I ignored it again.

Finally, I just today received a third email:

On 31 March 2012 13:30, Jen Rhee <thisisjenica@gmail.com> wrote:
Hi Eric,

I wanted to follow up once more to see if you received my previous email regarding a graphic I wanted to share about how Wikipedia is redefining the way we research. My team and I created it, and I would love to get your thoughts.

My apologies if you’ve received my request already, but let me know if you’d be interested in taking a look.

Much thanks,
Jen

This time, I decided to investigate a bit. It didn’t take me long to find a Twitter account for a certain Jenica Rhee which looks reasonably legit. But it also turns out that I am not the only one to receive emails from her. There is even a whole Google+ thread on the topic.

I must admit that this approach is smarter than the usual. The emails I got are really well written for an automated approach (could there be a real human being behind each of them?). The sample infographics I could find seem surprisingly well made (though accuracy is probably debatable). It is also not obvious how they got my email address, as it is not one of the two or three I use the most — although it is not hard to find it with a bit of Google’ing.

All in all, rather clever. And spam-worthy.

In this post, I am going to describe an interesting feature in Io, and how I extended it a bit to enhance an XML generator.

In the example provided, the following Io code:

Builder ul(
  li("Io"),
  li("Lua"),
  li("JavaScript"))

can generate the following output:

<ul>
<li>
Io
</li>
<li>
Lua
</li>
<li>
JavaScript
</li>
</ul>

This is made possible by redefining the forward method (“slot” in the terminology of Io), which is responsible for deciding who to apply the method calls (“message calls” in Io) to.
The other key thing is that it is possible to obtain the details on a message call, even when this message is not defined, a bit like what method_missing does in Ruby. This is done using call message.

For example, while this would be a normal method definition:

Builder myMethod := method("I have been called" println)

you could also do it awkwardly by redefining forward and using call message:

Builder forward := method(if(call message name == "myMethod", "I have been called" println))

This leads us to the following program (provided in the book) as a way to implement the Builder called in the example:

Builder := Object clone

Builder forward := method(
	writeln("<", call message name, ">")
	call message arguments foreach(
		arg,
		content := self doMessage(arg);
		if(content type == "Sequence",
			writeln(content)
		)
	)
	writeln("")
)

The exercise was to add indentation dependent on the depth of the tag. It turns out that slots (that is, members of classes or instances) can added to pretty much anything in Io, so I decided to add a depth slot to arguments. Here is the resulting Io code:

// create a sub-class ("prototype") of Object
Builder := Object clone

// redefine the forward method in order to intercept unknown method ("message") calls
Builder forward := method(
	// if the message does not have a "depth" attribute ("slot"), add it
	call message hasLocalSlot("depth") ifFalse(call message depth := 0)
	// indentation is "depth"-times a tab
	indent := "\t" repeated(call message depth)
	// open an XML tag, the name being the name of the message,
	// preceded by the indentation
	writeln(indent, "<", call message name, ">")
	// loop on each of the arguments of the message
	call message arguments foreach(
		arg,
		// increase the depth level for the sub-message call
		arg depth := call message depth + 1;
		// call the message represented by the argument on the current instance
		// (or on the current prototype, as it is the case here)
		content := self doMessage(arg);
		// check if the argument turns out to be a normal String
		if(content type == "Sequence",
			// prints the value of the argument, preceded by the indentation
			writeln(indent, content)
		)
	)
	// closes the XML tag
	writeln(indent, "")
)

With this, the folllowing code

Builder p (
	ul(
		li("Io"),
		li("Lua"),
		li("JavaScript")
	)
)

produces this result:

<p>
	<ul>
		<li>
		Io
		</li>
		<li>
		Lua
		</li>
		<li>
		JavaScript
		</li>
	</ul>
</p>

To sum up, we have created a DSL by redefining the way methods are called, introspecting the method call, and finally added a parameter to the method call (!).

If you want to read more about this technique, check out this other post on Io in the 7 Languages book. Curiously, Ben Nadel uses a variable on the Builder to store the current depth. That works, but it seems to me that it behaves just like a global variable, which wouldn’t be thread-safe. Also, I rather like associating a tag to its corresponding depth.

For example:

StandardFileSystemManager manager = new StandardFileSystemManager();
manager.init();
manager.resolveFile("ram://root/file.txt").createFile(); // prepare test harness
...
manager.resolveFile("ram://root/file.txt").getName(); // do something useful

Annoyingly, Apache VFS API provides a way to check if a file/folder is hidden, but, although it is always possible to manually create hidden files on your system, there is no way to mark a file as hidden in the RAM filesystem.

manager.resolveFile("ram://root/file.txt").isHidden(); // returns false
manager.resolveFile("ram://root/.file.txt").isHidden(); // also returns false

The solution is to modify the RAM filesystem and customize its checking of the hidden attribute. This means that we need a new RamFileProvider, a new RamFileSystem and finally a new RamFileObject.

In this example, all files and folders whose names start with a dot will be considered hidden:

public class RamFileProvider extends org.apache.commons.vfs2.provider.ram.RamFileProvider {
  @Override
  protected FileSystem doCreateFileSystem(FileName name, FileSystemOptions fileSystemOptions) throws FileSystemException {
    return new RamFileSystem(name, fileSystemOptions);
  }

  private static class RamFileSystem extends org.apache.commons.vfs2.provider.ram.RamFileSystem {
    public RamFileSystem(FileName rootName, FileSystemOptions fileSystemOptions) {
      super(rootName, fileSystemOptions);
    }

    @Override
    protected FileObject createFile(AbstractFileName name) throws Exception {
      return new RamFileObject(name, this);
    }
  }

  private static class RamFileObject extends org.apache.commons.vfs2.provider.ram.RamFileObject {
    public RamFileObject(AbstractFileName name, RamFileSystem ramFileSystemWithHiddenSupport) {
      super(name, ramFileSystemWithHiddenSupport);
    }

    @Override
    public boolean isHidden() throws FileSystemException {
      // this is the important part
      if (getName().getBaseName().startsWith(".")) {
        return true;
      }
      return super.isHidden(); // in practice, this always return false
    }
  }
}

Finally, this new RamFileProvider must be registered with your existing FileSystemManager. In my case, I get something like that:

StandardFileSystemManager manager = new StandardFileSystemManager();
manager.init();
manager.addProvider("ram-ext", new RamFileProvider());
manager.resolveFile("ram-ext:///root/file.txt").createFile();
manager.resolveFile("ram-ext:///root/.file.txt").createFile();
...
manager.resolveFile("ram-ext://root/file.txt").isHidden(); // returns false
manager.resolveFile("ram-ext://root/.file.txt").isHidden(); // returns true

Note that I did not replace the “ram” filesystem entirely. Although that would have been my preferred option, that would have taken too much time in my little experiment.

/**
 *
 */
@Test
public void testGetCustomerOK() {

  LOGGER.info("======= testGetCustomerOK starting...");

  try {
    CustomerDTO targetDTO = this.serviceImpl.getCustomer("ABC99");

    // Check.
    Assert.assertNotNull("Extra not found.", targetDTO);
    Assert.assertEquals("accountIds must be the same.", "ABC99", targetDTO.getAccountId());

  } catch (CustomerBusinessException exception) {
    LOGGER.error("CustomerBusinessException : {}",
	    exception.getCause());
    Assert.fail(exception.getMessage());
  } catch (UnavailableResourceException exception) {
    LOGGER.error("UnavailableResourceException : {}",
	    exception.getMessage());
    Assert.fail(exception.getMessage());
  } catch (UnexpectedException exception) {
    LOGGER.error("UnexpectedException : {}" +
	    exception.getMessage());
    Assert.fail(exception.getMessage());
  } catch (Exception exception) {
    LOGGER.error("CRASH : " + exception.getMessage());
    Assert.fail(exception.getMessage());
  }

  LOGGER.info("======= testGetCustomerOK done.");
}

Let’s see what I’d do with that.

Facing this code, the first thing I would do is remove the logs in the catch clauses, which are clearly obscuring the code the most. They do not provide actual value, since the exception message is used in Assert.fail() calls.

/**
 *
 */
@Test
public void testGetCustomerOK() {

  LOGGER.info("======= testGetCustomerOK starting...");

  try {
    CustomerDTO targetDTO = this.serviceImpl.getCustomer("ABC99");

    // Check.
    Assert.assertNotNull("Extra not found.", targetDTO);
    Assert.assertEquals("accountIds must be the same.", "ABC99", targetDTO.getAccountId());

  } catch (CustomerBusinessException exception) {
    Assert.fail(exception.getMessage());
  } catch (UnavailableResourceException exception) {
    Assert.fail(exception.getMessage());
  } catch (UnexpectedException exception) {
    Assert.fail(exception.getMessage());
  } catch (Exception exception) {
    Assert.fail(exception.getMessage());
  }

  LOGGER.info("======= testGetCustomerOK done.");
}

Next, the catching of exceptions and calling Assert.fail() is in fact the same work that the test runner actually does. We can let the test runner handle those cases:

/**
 *
 */
@Test
public void testGetCustomerOK() throws Exception {

  LOGGER.info("======= testGetCustomerOK starting...");

  CustomerDTO targetDTO = this.serviceImpl.getCustomer("ABC99");

  // Check.
  Assert.assertNotNull("Extra not found.", targetDTO);
  Assert.assertEquals("accountIds must be the same.", "ABC99", targetDTO.getAccountId());

  LOGGER.info("======= testGetCustomerOK done.");
}

The remaining logs are actually information that can already be known from the test runner, since test results are presented by methods. My guess is that they were added to make the previous logs more readable. They can go now:

/**
 *
 */
@Test
public void testGetCustomerOK() throws Exception {
  CustomerDTO targetDTO = this.serviceImpl.getCustomer("ABC99");

  // Check.
  Assert.assertNotNull("Extra not found.", targetDTO);
  Assert.assertEquals("accountIds must be the same.", "ABC99", targetDTO.getAccountId());
}

The “check” comment serves no useful purpose. Also, there is an empty comment that obviously adds no value:

@Test
public void testGetCustomerOK() throws Exception {
  CustomerDTO targetDTO = this.serviceImpl.getCustomer("ABC99");

  Assert.assertNotNull("Extra not found.", targetDTO);
  Assert.assertEquals("accountIds must be the same.", "ABC99", targetDTO.getAccountId());
}

We are down to 6 lines of code. The first assert does a check that is also done implicitely by the following one. That seems redundant. Also, it is clearly a situation that should not happen in a normal test run. That can go:

@Test
public void testGetCustomerOK() throws Exception {
  CustomerDTO targetDTO = this.serviceImpl.getCustomer("ABC99");

  Assert.assertEquals("accountIds must be the same.", "ABC99", targetDTO.getAccountId());
}

The remaining assertion has a comment that says what the test does. In some way, there is some value in this. However, in most (all?) cases, the person seeing the error would open the test class anyway and read the code. The test comment seems redundant. At the very least, its value is far from clear. In those situations, I remove the comments:

@Test
public void testGetCustomerOK() throws Exception {
  CustomerDTO targetDTO = this.serviceImpl.getCustomer("ABC99");

  Assert.assertEquals("ABC99", targetDTO.getAccountId());
}

OK, a little inlining can now be done:

@Test
public void testGetCustomerOK() throws Exception {
  Assert.assertEquals("ABC99", this.serviceImpl.getCustomer("ABC99").getAccountId());
}

The Assert.assertEquals method can also be statically imported:

@Test
public void testGetCustomerOK() throws Exception {
  assertEquals("ABC99", this.serviceImpl.getCustomer("ABC99").getAccountId());
}

And the test could use a renaming:

@Test
public void can_obtain_a_customer_by_account_id() throws Exception {
  assertEquals("ABC99", this.serviceImpl.getCustomer("ABC99").getAccountId());
}

Hm… the “this.” clause is not really necessary:

@Test
public void can_obtain_a_customer_by_account_id() throws Exception {
  assertEquals("ABC99", serviceImpl.getCustomer("ABC99").getAccountId());
}

And… that’s it. I’m down to 4 lines of code. There might be fewer comments, but I believe the result is a lot more readable.

That is one of the reasons I’m wince a little when a company talks about plans to hire lots of software developers.

This recent study by QSM seems to prove me right. Its conclusion seems to be that Brooks’s Law can be extended to projects that are not late. At any rate, code is not produced at a faster pace with more manpower.

The idea was to compare the time require to build a 100,000 lines projects, depending on the size of the teal. Results are :

• 32-people teams : 8.9 months
• 4-people teams : 9.1 months

That’s a one-week difference. 2-3%!

Costs are obviously much in favor of small teams (roughly 8 times cheaper for the same result!). One of the reasons suggested could be that large teams produce many more bugs.

Unfortunately, there are no discussions on other possible explanations, such as complexity in coordinating, communication, the number of managers, location over multiple rooms or sites, skills, turnover, size of the company… I would have also liked to see other sizes compared. Is there a productivity peak at 2 people ? 6 ? 4 ?

A few years ago, I got into a discussion where one of the persons remarked: “managing large teams is hard!” As far as as I’m concerned, the answer seems to be: “well, don’t do it, then.”

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…

@Test
public void should_search_by_path() {
	Searcher searcher = new Searcher();
	Path location = new Path("somewhere");
	String data = "data";

	searcher.putAt(data, location);

	assertThat(searcher.findAt(location), is(data));
}

It seems that many developers consider this good code. I don’t. My main gripe here is that the presence of variables does not add much useful information. Instead, they make the code too verbose.

A first rewrite would produce something like that:

@Test
public void should_search_by_path() {
	Searcher searcher = new Searcher();
	searcher.putAt("data", new Path("somewhere"));

	assertThat(searcher.findAt(new Path("somewhere")), is("data"));
}

Shorter, which is good. I also like the fact it makes clear that it is the value of the parameters that matter, and not their pointers.
We can go further by leveraging local static methods.

@Test
public void should_search_by_path() {
	Searcher searcher = new Searcher();
	searcher.putAt("data", path("somewhere"));

	assertThat(searcher.findAt(path("somewhere")), is("data"));
}

private static Path path(String path) {
	return new Path(path);
}

(a static method is not mandatory, but I think it makes its intention of being a utility method clearer)
And, finally, if this test class is dedicated to the Searcher class, I would probably make the searcher variable a field, as it would be used in most test methods.

private Searcher searcher = new Searcher();

@Test
public void should_search_by_path() {
	searcher.putAt("data", path("somewhere"));

	assertThat(searcher.findAt(path("somewhere")), is("data"));
}

private static Path path(String path) {
	return new Path(path);
}

This is more lines than the original example. However, the searcher variable is on top of the class and the path() method is at the bottom, far out of the way of the test methods. Indeed, I would often have several such static methods at the bottom of my classes (and, rarely, one or two more instance variables at the top). I even tend to do so when I have such a single method using them.

Beside the fact that the method has fewer lines, I also like that it makes for more fluent code. It almost reads like a story “when the searcher is being put a String of value ‘data’ at the path of name ‘somewhere’, then it should be able to assert that the String found at the path of name ‘somewhere’ has value ‘data’”.

Another example, so that my position is clear:

@Test
public void should_find_by_address() {
	String aValidAddress = "10 Downing Street";
	Person aPerson = new Person("David Cameron");
	contacts.put(aValidAddress, aPerson);

	assertThat(contacts.get(aValidAddress), is(aPerson));
}

I’d very much rewrite this as follows:

@Test
public void should_be_able_to_find__a_person_when_storing_with_a_valid_address() {
	contacts.put("10 Downing Street", person("David Cameron"));

	assertThat(contacts.get("10 Downing Street"), is(person("David Cameron")));
}

Any thoughts?

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.

In general, when I test classes that have dependencies, my favorite approach is to pass those dependencies to the constructor:

public class MyService {
	private final MyDependency myDependency;

	public MyService(MyDependency myDependency) {
		this.myDependency = myDependency;
	}
}

Which makes creating test harnesses with Mockito reasonably easy:

public class MyServiceTest extends UnitTest {
	@Test
	public void shouldComputeAResult() {
		MyDependency mockMyDependency = mock(MyDependency.class);
		when(mockMyDependency.findSomeValue()).thenReturn("some value");

		MyService service = new MyService(mockMyDependency);

		assertThat(service.computeSomething(), equalTo("result"));
	}
}

However, it appears that Guice, at least under version 1.1.1 of its Play module, can only be used with Play to inject into static members:

@InjectSupport
public class MyService {
	@Inject
	static MyDependency myDependency;
	// no constructor (a default constructor will be
	// generated automatically by Play Framework)
}

The @InjectSupport is what makes the Guice module detect that the class requires dependencies (a class that extends either com.google.inject.AbstractModule or play.modules.guice.GuiceSupport must also be present in the classpath).

This makes it hard to instrument classes under test, as the value for a mock instance of MyDependency is shared amongst all tests that run currently.

public class MyServiceTest extends UnitTest {
	@Test
	public void shouldComputeAResult() {
		MyDependency mockMyDependency = mock(MyDependency.class);
		when(mockMyDependency.findSomeValue()).thenReturn("some value");

		MyService service = new MyService();
		// static values are brittle;
		// they should not be touched in unit tests
		service.myDependency = mockMyDependency; // yuck!

		assertThat(service.computeSomething(), equalTo("result"));
	}
}

Many subtle problems may occur when injecting dependencies in this way. For example, all instances of MyServices used concurrently will point to the same dependencies instances, so it is possible that tests will behave in inconsistent ways. Also, it makes it harder to default to sensible (null) dependencies, since tests running in the same JVM will by default use dependencies set by the first test.

The solution I’m using is to add providers in your Guice module:

public class GuicyModule extends AbstractModule {
	@Override
	public void configure() {
		// no code needed
	}

	@Provides
	public MyService getMyService(MyDependency myDependency) {
		return new MyService(myDependency);
	}
}

In this way, you are making sure that the dependencies are passed as you wish. Also, it will not be necessary to add any sort of Guice-related code in my services:

public class MyService {
	private final MyDependency myDependency;

	public MyService(MyDependency myDependency) {
		this.myDependency = myDependency;
	}
}

The downside is that you do have a few more lines to maintain, which is never fun. Better than the alternative, though.

My thanks to David Gageot who told me about providers in Guice.