| Newsgroups |
gmane.comp.java.junit.user |
| Message-ID |
<[email protected]> |
inline.
>> 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 think you could use Class.isAssignableFrom(Class) instead, but if you could give more context, I could give a better suggestion. More context would also allow me to update the release notes to warn about this.
Like I said, our code is IMO overly restrictive and I agree that isAssignableFrom should work as well, so I would assume it is unlikely that anyone else would run into this issue.
>
>I believe we introduced the external AssumptionViolatedException so that projects would not have to import internal classes. If introducing the external AssumptionViolatedException causes a lot of problems, then maybe we need to just accept that AssumptionViolatedException should not have been internal but we can't do anything about it.
See above. Keep it as you have it in the beta
>
>
>
>> 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 filed https://github.com/junit-team/junit/issues/975 to track this.
>
>On the one hand, it would be nice if we were free to make non-backwards-compatible changes to internal classes. On the other hand, we have had some classes that were internal when they shouldn't have been. In this particular case, it would be trivial to add the method back (and the method is trivial to maintain going forward), so IMHO we should add it back.
>
>
>> 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.
>
>JUnitSystem is an internal class. If you believe we should have an external version, could you please file a feature request and outline your use case?
The use case is that we have implemented a replacement for JunitCore (not inheritance due to how our project needs to work) and we test it the same fashion as JUnitCoreTest, i.e. we have something similar to runMain and pass it in a JUnitSystem (an anonymous implementation in the testcase). As I said, it's not a big issue, I can live with copying something like MainRunner into our test tree, your call.
I don't have an account on github and am a bit too lazy to create one to file a report on this ;) As I said in my initial mail, I'm fine with this release.
/Chris
------------------------------------
Posted by: Chris <[email protected]>
------------------------------------