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

Henrik,

For JUnit4ClassRunner, it may be easiest to boil down to a particular
example.  Would you mind choosing one third-party runner that currently
extends JUnit4ClassRunner, so that we can see how this choice affects users
of that library?

   David Saff


On Mon, Aug 4, 2014 at 6:40 AM, [email protected] [junit] <
[email protected]> wrote:

>
>
> Hello
>
> I am sorry for trashing the party but I have a couple of concerns that are
> very likely to slow down the adoption of JUnit-4.12 among the providers of
> 3rd-party tools ...
>
>  --- 1) Don't remove JUnit4ClassRunner! (in package
> org.junit.internal.runners)
>
> I have developed a number of 3rd-party runnners myself and I want the
> JUnit community to know that as a 3rd-party runner developer you want the
> latest version of your runner to work with any version of JUnit! -
> Otherwise the end-users (test-developers) will be less likely to start
> using your runner because they probably don't want to deal with the
> version-conflict hell that might raise between JUnit and your 3rd-party
> runner.
>
> A couple of good examples are the 3rd-party runners MockitoJUnitRunner
> (from Mockito - http://mockito.org) and CallbackParamsRunner (from
> CallbackParams - http://callbackparams.org)
>
> Both runner implementations extends JUnits Runner base-class. They both
> work as thin wrappers that hand over the main part of the test-execution to
> whichever JUnit-runner is appropriate for the JUnit-version on classpath,
> while they stay in the background ensuring that their intended features are
> magically appended on the test-execution with whichever extension points
> are appropriate for the JUnit-version at hand.
>
> In this manner the runners will work with JUnit-4.4 (or even older
> versions) but they will also work fine with later JUnit-versions, therewith
> allowing their end-users to upgrade JUnit separatly in order to also
> benefit from new JUnit-features (such as JUnit-rules etc).
>
> Now I do think that both of these runners will run just fine with
> JUnit-4.12-beta-1 but their builds would fail the day they decide to
> upgrade their JUnit dependency (e.g. if they want to leverage from some new
> JUnit feature in 4.12). - So in the end this will slow down the adoption of
> 4.12 in these 3rd-party projects because an upgrade would force their
> communities to extra efforts in order to preserve their
> backward-compatibility to older JUnit-version (such as 4.4).
>
>  --- 2) Please remove pull-request #625 from the release! (The annotation
> @RunListener.ThreadSafe)
>
> I think this pull-request represents a very poor design choice that - at
> best - might help performance only for JUnit runners that executes their
> tests with concurrent threads. I would like to point out that most smaller
> unit-tests do not!! - but they still suffer from the same RunListener
> slowness that this issue is supposed to address ...
>
> A much better solution that would be generally beneficial to all types of
> JUnit runners would be to offer RunListener implementors some sort of
> concurrency API that allows RunListener implementations to use
> assynchronous execution of the parts that might take a long time. - That
> way it would be possible for all runners to seamlessly benefit from
> RunListeners that have clever assynchronous concurrency features!!
>
> I can discuss this RunListener stuff forever but I don't really have the
> time - so I invite other clever people to join the discussion ...
>
> ---
> BR /Henrik Kaipe
>  
>