On 2 October 2010 15:08, Phil Steitz <phil.ste...@gmail.com> wrote: > On 10/1/10 10:52 AM, Luc Maisonobe wrote: >> >> Le 01/10/2010 16:34, Gilles Sadowski a écrit : >>> >>> On Fri, Oct 01, 2010 at 03:17:58PM +0100, sebb wrote: >>>> >>>> There are quite a few test cases that have code like: >>>> >>>> public void testSomething(){ >>>> try { >>>> something(); >>>> fail("an exception should have been caught"); >>>> } catch (EstimationException ee) { >>>> // expected behavior >>>> } catch (Exception e) { >>>> fail("wrong exception type caught"); >>>> } >>>> } >>>> >>>> This is unnecessary code; worse, the actual Exception is lost. >>>> >>>> I propose to fix these by converting them to: >>>> >>>> public void testSomething() throws Exception { >>>> try { >>>> something(); >>>> fail("Expecting EstimationException "); >>>> } catch (EstimationException ee) { >>>> // expected behavior >>>> } >>>> >>>> Any objections? >>> >>> Shouldn't we move to JUnit 4, i.e. using >>> ---CUT--- >>> @Test(expected=EstimationException.class) >>> public void testSomething() { >>> something(); >>> } >>> ---CUT--- >> >> I agree JUnit 4 is the way to go here. We already have some JUnit 4 >> tests, we simply did not change everything when we switched to Java 5 >> and change the tests slowly. >> >> This is a good opportunity for these tests, so +1 for the switch here. >> > > I am personally not in love with using annotations in test code, but that > train has left the station, so +0 if someone else wants to do the boring > work to change everything. Please be careful though not to lose sensitivity > in the tests.
+1. > +1 for sebb's original suggestion - the exception should not be lost. I've done that already ... > Phil >> >> Luc >> >>> >>> [Of course, this would force to split the test methods that currently >>> contain multiple statements that can throw an exception.] >>> >>> >>> Gilles >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org