I guess the root of this issue then is what is 'shouldFailWithCause' supposed to assert about the passed Class and Closure and how is it different from shouldFail(Class,Closure)?
Unfortunately we're running into having no javadoc on the method, the only other bug am currently finding that mentions shouldFailWithCause is
GROOVY-1247 (which seems to be related to return values), and fisheye unfortunately isn't helping find when it was added given that HEAD of GroovyTestCase currently indexed as r6778 where the method does not exist yet...
Based upon the naming convention, I interpreted shouldFailWithCause(Class,Closure) to mean that I expect a particular closure to throw any Throwable that has a cause of the specified class, thus distinguishing it from shouldFail(Class,Closure) which seems to asserts that the closure throws a Throwable of the specified class.
The issue I have with shouldFailWithCause also handling the case where getCause() == null is that then we have a state where this one method sometimes makes an assertion about the thrown Throwable, and sometimes makes an assertion about the thrown Throwable's cause, making our tests unclear as to which is the case.
If my interpretation of purpose behind shouldFailWithCause is true, then the tests were written incorrectly in the first place, and we should deliberately break them. If I'm wrong, then we need to make sure to change shouldFailWithCause so that it only asserts one state since philosophically having a method that asserts multiple different states makes any test utilizing it ambiguous to begin with. (Since no matter what we'll wind up breaking someone with any change, we probably should slate it for groovy 1.8).
And of course this is a separate discussion from whether or not the change to let RuntimeExceptions fall through as is was indeed correct.