Re: Concept question about JUnit Failures
On Wed, 19 May 2010, Patricia Shanahan wrote:
Lew wrote:
Rhino wrote:
and failed to acknowledge Daniel Pitts, who said:
public void testParseException() {
try {
myObj.getRGB("Bad value!");
fail("Bad value did not cause exception!");
} catch(IllegalArgumentException e) {
// Success!
}
}
public void testGoodParse() {
assertEqual(white, myObj.getRGB("FFFFFF"));
}
Rhino:
Thank you VERY much for the speedy AND accurate answer! It never
occurred to me to try that! It solves my problem very simply and
elegantly. :-)
Tom Anderson wrote:
Not as elegantly as my solution!
Indeed. As someone who is just now getting used to JUnit 4 and who loves,
nay, adores annotations, I found tom's response exceedingly enlightening.
I have a slight problem with using the annotation approach alone. It can
only check for a throw of appropriate type. It cannot check other
features of the thrown object, such as its message or a wrapped
exception. As far as I can tell, a catch block is the only way to fully
test if the interface promises anything beyond a throw type.
Very true. Daniel's point about not being able to make assertions about
the throwing object after the throw is also a good one. I suppose i'd
retreat slightly and say the expected exception method is appropriate when
you just want to check that the right exception is thrown, because it's
easy, it makes the intent clear, and it gives you a nice error message,
but if you want to do anything more, it's no use.
It also runs the risk of silently letting bugs pass in situations like
this:
@Test(expected=IndexOutOfBoundsException.class)
public void testGetThrowsExceptionForBadIndex() {
List<String> l = new MyList();
l.add("hello");
l.get(1);
}
This is written to check that get correctly throws an exception - but if
add incorrectly throws an exception, it will still pass.
So now i'm thinking about retreating even further.
tom
--
OK, mostly because of Tom, but not only because of his bloody irritating
character and songs.