Re: Re: JUnit 4.12-beta-1 is released

--------------------------------------------
On Mon, 8/11/14, Kevin Cooney [email protected] [junit] <[email protected]> wrote:

 Subject: Re: [junit] Re: JUnit 4.12-beta-1 is released
 To: [email protected]
 Date: Monday, August 11, 2014, 6:02 PM
       
 On Mon, Aug 11, 2014 at
 3:54 AM, [email protected]
 [junit] <[email protected]>
 wrote:
     
       Hi,
 
 I've tried
 porting an in-house runner that previously has been using
 4.8 into 4.12-beta-1 and and I've found no issues that
 must be fixed. So to me it looks ready for release.
 
 One thing that was slightly
 annoying is that instead of removing
 org.junit.internal.AssumptionViolatedException, you've
 deprecated and duplicated it into
 org.junit.AssumptionViolatedException. This caused me some
 headache as we had code catching the former class type and
 suddenly it looked like assumptions had stopped working
 until I realized I had to change the import statement. For
 the future, I'd prefer that you just remove the original
 class as then we'll get a compiler error instead of
 runtime failures.
 
 
 
 
 Thanks for the feedback,
 Chris
 Could you give
 us an example of the code that was broken by our
 introduction of an external AssumptionViolatedException? The
 new external one is a subclass of the internal one, so the
 thinking was any code outside of JUnit that tried to catch
 the internal AssumptionViolatedException would still catch
 exceptions thrown by Assume. Was your code specifically
 throwing the internal AssumptionViolatedException? I thought
 we handled that as well.
 
 
 
 I would be very interested
 in knowing more details.
 -- Kevin
 
 
-----
(yahoo seems to mangle my reply, sorry for bad formatting)
Hi,

to some extent, I think it was the fault of our code using it, which seems overly restrictive:
if (<something> && exception.getClass().equals(org.junit.internal.AssumptionViolatedException.class))

I never checked when is actually thrown, but if it is the internal one that gets here, then of course that statement is too restrictive. I don't know if there was some reason for doing it that way or not, though. Easy to work around, though ;)
We were also throwing the "internal exception" in some of our unit tests so I changed those to the external one, but I don't know if that gave me any problems or not.
     
By the way, the removal of "exit()" from JUnitSystem was a bit annoying as I ended having to copy in MainRunner (from your tests) into our project as we're also testing some System.exit conditions. I can see why it is nicer to remove a test-only API from the source part, but when the cost is 290 lines of MainRunner to save JUnitSystem subclasses from writing a 3-line method, then I'm not so sure it is a gain. But I can live with it.



------------------------------------
Posted by: Chris <[email protected]>
------------------------------------