Andreas Korneliussen wrote:
> Daniel John Debrunner wrote:
>
>> DerbyJUnitTest has many cases where the SQLException thrown by Derby
>> (through JDBC) is ignored. To me, this seems very bad practice for test
>> code.
>>
> Isn't that bad practice for any code ?
True, but it's *very* bad practice for test code. :-)
> Anyway, I think there are cases when you are interested in not throwing
> the SQLException to the JUnit framework.
>
> If your test has already failed with a meaningful assertion which
> describes the error, the junit- test runner will call the tearDown()
> method on your TestCase object, which may throw an exception.
> If the tearDown() throws i.e "ResultSet is closed", that error will
> overwrite the original test failure in the JUnit test report.
Thanks for that, I didn't know that. I agree there may be cases where
you want to hide an exception, maybe a specific exception, but it should
not be the normal case for test code. Maybe the parent class
DerbyJUnitTest should have a final tearDown method that calls an method
and catches all SQLExceptions are reports them. Or such close methods
should be called tearDownClose() to indicate they are only to be used in
tearDown.
rough example
public final void tearDown()
{
try {
derbyTearDown();
} catch (SQLException sqle)
{
reportExceptionSomeHow(sqle);
}
}
// tests can implement this method to provide test
// specific teardown.
protected void derbyTearDown() throws SQLException
{
}
Dan.
