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

"Kevin Cooney [email protected] [junit]" <[email protected]> Tue, 12 Aug 2014 12:08:09 -0700
Newsgroups gmane.comp.java.junit.user
Message-ID <CAA3E+eUS7VfERmS=Q6oy=Wf1g9_XaTY1T=TCX-bJaVnKr30PuQ@mail.gmail.com>
Having JUnit4ClassRunner's constructor throwing an exception would make it
difficult for someone to provide a drop-in replacement for that class
(without unjar'ing the JUnit jars and removing the class files), so I'm not
sure that's a great option either.

Has someone verified whether removing JUnit4ClassRunner will break projects
using Mockito's runner? It looks like for projects that use Mockito and use
JUnit 4.5 or later, Mockito doesn't use JUnit4ClassRunner; see
https://github.com/mockito/mockito/blob/master/src/org/mockito/internal/runners/RunnerFactory.java#L27

-- Kevin

On Tue, Aug 12, 2014 at 10:53 AM, [email protected] [junit] <
[email protected]> wrote:

>
>
> Hi DavidI have tried 4.12-beta-1 on a number of problem scenarios. There
> will be some problems with publicly available 3rd-party runners but the
> most serious consequences (for end-users) will probably show up where they
> have some customized in-house runner ...public class
> Somebodies_Inhouse_Runner extends JUnit4ClassRunner {  public
> Someones_Inhourse_Runner(Class<?> testClass) {super(testClass);}}... and a
> common test super-class ...@ RunWith(Somebodies_Inhouse_Runner.class)public
> abstract TestSuperClass { /* Common test-utils go here! */ }... both of
> which class-files are available on the test class-path (perhaps in a
> separate jar-file).A test that extends TestSuperClass ...public class
> BrokenTest extends TestSuperClass {  @ Test  public void myTestMethod()
> {}}... will compile and run as expected with JUnit-4.11. With 4.12-beta-1
> it will still compile (without warnings!) but the test-run will result in
> this error message:"Type [unknown] not present"(I have verified this
> scenario with JDK-7)My opinion on this:Keeping JUnit4ClassRunner - and
> finalize its deprecation by having its constructor throw an understandable
> error-message - would leave the JUnit community with a maintenance burden
> that is insignificant compared to the burden of finding out the meaning of
> "Type [unknown] not present"!BR /Henrik Kaipe
>  
>