Original issue created by wesalvaro@google.com on 2013-11-28 at 01:55 AM
I recently was changing my tests to JUnit4 and it was suggested to use an @Rule ExpectedException instead of my try/catch(expected).
But how do I verify things after my exception is thrown?
I created a Matcher that I expected as well that would verify the stuff after the exception, but that's clumsy and over-complicated. The fact of the matter is that ExpectedExceptions just don't work well when you need to verify things after the exception is thrown.
I pointed this out to a colleague who was taken aback and immediately searched and found places where ExpectedExceptions were used with verification done after the method threw its exception... Bad news: That verification was never done.
I searched the broader code base and found that he was not alone. It seems that the magic of ExpectedException has caused devs to be lax with how exceptions actually work. Nothing executes after the exception is thrown, of course, but I was able to find several instances of people doing work after the method throws. =(
There can be two varieties of this check:
Error: When there exists statements after the throwing function.
Warning: When there exists statements before the throwing function (i.e. between the throwing function and the call to ExpectedException#expect).
Both are bad with the latter being only bad test style, the former, however, is broken tests.
I'm not super familiar with how error-prone tests are created, but I was able to throw something together with a RegEx, so error-prone seems ideal.
Original issue created by wesalvaro@google.com on 2013-11-28 at 01:55 AM
I recently was changing my tests to JUnit4 and it was suggested to use an @Rule ExpectedException instead of my try/catch(expected).
But how do I verify things after my exception is thrown?
I created a Matcher that I expected as well that would verify the stuff after the exception, but that's clumsy and over-complicated. The fact of the matter is that ExpectedExceptions just don't work well when you need to verify things after the exception is thrown.
I pointed this out to a colleague who was taken aback and immediately searched and found places where ExpectedExceptions were used with verification done after the method threw its exception... Bad news: That verification was never done.
I searched the broader code base and found that he was not alone. It seems that the magic of ExpectedException has caused devs to be lax with how exceptions actually work. Nothing executes after the exception is thrown, of course, but I was able to find several instances of people doing work after the method throws. =(
There can be two varieties of this check: Error: When there exists statements after the throwing function. Warning: When there exists statements before the throwing function (i.e. between the throwing function and the call to ExpectedException#expect).
Both are bad with the latter being only bad test style, the former, however, is broken tests.
I'm not super familiar with how error-prone tests are created, but I was able to throw something together with a RegEx, so error-prone seems ideal.