Re: Java - Junit distinguish exceptions
On Fri, 10 Dec 2010, Ronny Mandal wrote:
On 10 Des, 10:14, Ronny Mandal <ronn...@ifi.uio.no> wrote:
Hello, I am relatively new to JUnit. I am instrumenting already
existing tests, what I want to do is to record which exceptions that
(could) occure when running the tests. One sometimes expected exception
is java.lang.SecurityException, i.e. it might be thrown, but not
necessarily. The other does not matter, all that I am interested in is
that an exception has occured.
Firstly, this doesn't sound like a good test at all. An exception 'might
be' thrown, and that's okay? Why? Why is it okay for the test to do
different things at different times?
So my results would be Pass / Fail / SecurityException (Other exception
would normally be recorded as an error. I cannot use
@Test(expected=...), because the test would fail if no exception was
thrown. It is preferrable not to duplicate the test methods, where one
has an expected exception.
Any suggestions is greatly appreciated.
Strange thing, the answer always emerges when the question is asked.
WHen an exception occurs, a stack trace is yielded. Capture this,
parse it and suddenly the task is done!
That doesn't sound like a good solution at all. Where are you doing the
capturing and parsing? In the test? In general, you can't really rely on
the stack trace in an exception, since it can vary at the whim of the
optimiser. Plus, parsing stack traces is just a hacky thing to do.
Now, in advance of an answer to my question above, i'm going to make an
assumption about what's going on here. I think that you're running these
tests in different contexts; sometimes, the test can work, but sometimes,
something it needs to do is blocked by the security manager, and you get
the SecurityException. The reason you don't consider this a failure is
that it means the test could not be carried out, not that the test failed.
In that case, you can make use of a somewhat obscure JUnit feature called
'assumptions': an assumpion is just like an assertion, except that if it
fails, then rather than causing the test to fail, it causes it to be
ignored. See:
http://junit.sourceforge.net/javadoc/org/junit/Assume.html
You can write your test like this:
import static org.junit.Assume.assumeNoException;
@Test
public void testStuff() {
try {
// whatever
}
catch (SecurityException e) {
assumeNoException(e);
}
}
If you get a SecurityException, the test will be ignored.
A warning: be careful with these. Remember that an ignored test is not
testing anything. Every test that ends up being ignored is something about
your system that is not being tested. Ignores are in a way more dangerous
than failures, because they're so easy to overlook: if you have ninety
passing tests and ten ignored, with no failures, you tend to think your
system is okay, whereas in reality, the features covered by the ten
ignored tests could be disastrously buggy. In general, i think it's better
to have test which cannot be carried out fail rather than be ignored,
because it makes you aware of this problem. Consequently, i'd say the only
time ignored tests are useful is if you're monitoring their number; if an
ignored tests is a cause for concern in the same way as a failed test,
then you can make good use of them. But for most people, ignored tests are
just ignored.
tom
--
william gibson said that the future has already happened, it just isn't
evenly distributed. he was talking specifically about finsbury park. --
andy