Rick Hillegas wrote:
Alternatively, we could print out the stack trace ourselves. The logic
to do this could be re-usable by a general-purpose assertEquals()
overload which compares two Throwables. Failing by calling
assertEquals() seems like the way the JUnit wants to track errors.
I think it is perfectly acceptable to let the test methods throw
"unexpected" exceptions as they are.
Many of our tests are a little special, because the only type of checked
exceptions that can be thrown is SQLException. Thus we catch all
exceptions with one catch-block.
For instance I think this kind of code is okay:
public void testSomething()
throws XException, YException {
methodCanThrowXException();
mayThrowYException();
methodCanThrowXException();
try {
shouldThrowYException();
fail("An YException should have been thrown");
} catch (YException ye) {
assertEquals("myState", ye.getYState());
}
}
I don't want to clutter my code with try-catches for unrelated
exceptions, there's nothing I can do anyway. And if the unimaginable
should happen and XException is thrown, I will have the stack trace (and
hopefully other tests) to guide further investigations.
In the code above, note that the try-catch block is made as small as
possible.
As Knut Anders, I also feel some information is missing when the tests
fail. A five character SQLState does not tell me very much, and often I
have to consult the messages file to see what it means! As a Derby
example, let's say the method shouldThrowYException intermittently
throws an exception with SQL state XSRS7.
Basically, this is what we have:
"expected: XSRS1, actual: XSRS7"
Let's consult the message text of XSRS7 for help:
"Backup caught unexpected exception."
That's all we got, and I don't feel too happy about that.
I can guess that some kind of IO exception caused this, but I want
Derby/JUnit to tell me so I can be sure. If it can tell me where the
error happened as well, it would be great!
Last, if the SQL state is not as expected, the test should result in a
failure, not an error, but still preserve the stack trace.
Any suggestions on how we can achieve what Knut Anders is proposing?
I think it is a good proposal to preserve the stack trace, the error
message and the SQL state.
--
Kristian
Regards,
-Rick
Knut Anders Hatlen wrote:
Currently, BaseJDBCTestCase.assertSQLState() and JDBC.assertSQLState()
basically do an assertEquals() on the SQL state. If the SQL state
doesn't match the expected value, an AssertionFailure is raised, but
the original exception is thrown away.
Should we instead do something like this
if (!expected.equals(sqle.getSQLState())) throw sqle;
?
This way, we preserve the stack trace and the error message, not only
the SQL state.
