Dave W. Smith

I’m doing a cram course in Java dependency injection (DI) frameworks, and am coming away tentatively impressed with Guice, a new framework by two guys at Google who I know to be highly competent, and, more importantly, tasteful Java developers. They’ve spent time grappling with bloat, and it shows in their design. Guice is a lot lighter weight than DI in Spring, and makes good use of Java5 annotations. The caveat with Guice is that it’s still early days, and the (limited) documentation has some gaps that require educated guesses (and dives into the Guice Javadoc) to fill in.

Having unit tests can sometimes lead to a false sense of security, particularly when you appear to have 100% code coverage but are actually still missing a test.

I ran into an instance of one problem pattern a few days ago. From the test side, it looked something like this:

public void testEncryptIsReversable() {
  String s = "some string";
  String e = encrypt(s);
  assertEquals("decrypt should reverse encrypt", s, decrypt(e));
}

See the problem? It’s easy to miss. I almost read right past it when encountering it in a larger, more complicated test.

Here’s the improved test:

public void testEncryptIsReversable() {
  String s = "some string";
  String e = encrypt(s);
  assertNotEquals("encrypt should have some effect", e, s);
  assertEquals("decrypt should reverse encrypt", s, decrypt(e));
}

This might seem silly. Of course encrypt is going to return different bits, especially when you’re using a well-tested library. But if you step back and look at this as an example of using transformation code that someone else on a project is providing, (as was the case in the code I was looking at), does it not make sense to add a tiny bit of protection against their accidentally checking in a stub implementation? Say, right before they have to run off to a meeting, and then forget correct their mistake?

It’s surprising how long little lapses can go undetected in a large project, especially when we have that false confidence that comes from almost complete tests.