| Newsgroups |
gmane.comp.java.junit.user |
| Message-ID |
<[email protected]> |
David,
I think Henrik had mockito in mind. The class in question is
https://github.com/mockito/mockito/blob/master/src/org/mockito/internal/runners/JUnit44RunnerImpl.java
It is deprecated, since the mockito maintainers are well aware that the
JUnit4ClassRunner is deprecated.
But the mockito team offers their JUnit44 runner for those people who
want to run the newest version of Mockito together with a pre-4.4
release of junit (for whatever reason). Post-4.4 users can just use the
regular 'MockitoJUnitRunner'.
With JUnit 4.12, this mockito trick won't compile anymore if I'm not
mistaken.
Thus, Mockito needs to ship a new release so that Mockito builds with
the new JUnit. That new Mockito release will likely break for older
users, who do not wish to upgrade their JUnit version.
I think Henrik argues that this is quite common: This query, for
example, yields 2800 results:
https://github.com/search?utf8=%E2%9C%93&q=junit4classrunner+NOT+deprecated&type=Code&ref=searchresults
This is my understanding of the problem -- hope it helps.
Arie
David Saff [email protected] [junit] schreef op 11/08/14 19:33:
> 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]
> <mailto:[email protected]> [junit] <[email protected]
> <mailto:[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
>
>
>
------------------------------------
------------------------------------