This first appeared on my old blog in November 2008.
I’ve decided that I don’t like typical patterns for testing exceptions. I decided this a while ago as far as “Expected Exception” attributes/annotations are concerned and stuck with the traditional try/catch approach (I’ll explain why in a minute). Now, I’ve decided I don’t like the typical “try/fail or catch” approach and have started using a subtle evolution of it.
First, let me explain why I don’t like Expected Exception attributes/annotations. The final nail in the coffin of this approach was hammered home for me when working with Liz Keogh a while back.
Here is an example in Java of your expected exception pattern (for brevity I won’t include assertions for e.getMessage()):
@Test(expected=BeyondMyExpertiseException.class)
public void shouldComplainWhenNotAClass() throws Exception {
DomainExpert expert = new DomainExpert();
String thisCheckpoint = nameOfSomeInterface();
expert.howDoIRestore(thisCheckpoint);
}
So, apart from the obvious fact that it is only implicit as to which method threw that exception (because I know that none of the other steps can throw that exception)… and we want our tests to communicate information explicitly, yes? The insight that Liz shared with me is that it changes the flow of information (ok, I’m paraphrasing now) compared to a test that doesn’t expect an exception.
In a ‘positive’ test, the flow of information that is expressed to the reader is What I need->what I do->what I expect. In an expected exception test, this is changed to what I expect->what I need->what I do. The latter just doesn’t flow very well and because it’s different to your positive tests there’s an overhead involved for the reader (me or someone else later on) to process this shift in structure… I’ve found that such tests just don’t jump out at me when I’m scanning the tests…
Since then, despite fashion, I committed to the old-fashioned way of writing exceptions – “try/fail or catch”:
@Test
public void shouldComplainWhenNotAClass() throws Exception {
DomainExpert expert = new DomainExpert();
String thisCheckpoint = nameOfSomeInterface();
try {
expert.howDoIRestore(thisCheckpoint);
fail("Should have thrown " +
BeyondMyExpertiseException.class.getSimpleName());
} catch (BeyondMyExpertiseException e) {
}
}
Ok, I accept, it looks more cluttered by comparison but the flow of information makes more sense and I make it explicit that the expert.howDoIRestore(thisCheckpoint) method call is the one that should have thrown the exception. (Note: The idea here is not to reduce how much you type but to make the test more expressive). The “try/fail or catch approach only works when your code doesn’t throw an exception… If your code throws a different exception, the failure trace just tells you what exception was actually thrown, it doesn’t tell you what exception was expected. So, here is a slightly different way of writing it:
@Test
public void shouldComplainWhenNotAClass() throws Exception {
DomainExpert expert = new DomainExpert();
String thisCheckpoint = nameOfSomeInterface();
try {
expert.howDoIRestore(thisCheckpoint);
fail();
} catch (Exception e) {
assertThat(e,is(instanceOf(
BeyondMyExpertiseException.class)));
}
}
Notice that I’m only catching Exception now, not BeyondMyExpertiseException. This still feels a little jumbled… Because my assertion is inside the catch block, I have to have the fail() method call just after the call that should throw the exception. Hmmm… don’t like that… Instead, this makes more sense:
@Test
public void shouldComplainWhenNotAClass() throws Exception {
DomainExpert expert = new DomainExpert();
String thisCheckpoint = nameOfSomeInterface();
Exception thrownException = null;
try {
expert.howDoIRestore(thisCheckpoint);
} catch (Exception e) {
thrownException = e;
}
assertThat(thrownException,is(instanceOf(
BeyondMyExpertiseException.class)));
}
Giving this failure trace when it fails:
java.lang.AssertionError:
Expected: is an instance of
com.testingreflections.atdd.expertise.
misunderstanding.BeyondMyExpertiseException
got: < java.lang.UnsupportedOperationException >
So, for those who want to type as little as possible, this isn’t for you… But if you want tests that drive out your exception handling to be more expressive, then this is an alternative to the usual “try/fail or catch” approach. I think that perhaps there’s an even better way of doing this… maybe next I’ll see how approximating closures with an anonymous class might help improve the readability of this… Let me know if you know of a better way.
