Okhttp: Provide a JUnit 5 extension for MockWebServer

[fbiville]

I'm trying to get rid of JUnit 4 in my project and the last remaining bit is MockWebServer which depends on org.junit.rules.ExternalResource.

That is not a blocker as org.junit.jupiter:junit-jupiter-migrationsupport provides experimental support for this.

However, it would be great to provide an implementation of MockWebServer following the Junit 5 extension model.

[yschimke]

This was discussed here https://github.com/square/okhttp/pull/3139

It's considered public api, so the change has to be very carefully handled. Introducing a junit library is simpler but essentially wouldn't need to be a part of the core project either.

[fbiville]

Thanks for the quick response.

but essentially wouldn't need to be a part of the core project either

Not sure I am following: by core project, do you mean OkHttp or MockWebServer?

Given JUnit 4 and 5 can be both in the classpath afaik, what about adding JUnit 5 to MockWebServer and introducing a new class like MockWebServer(JUnit5)Extension without introducing visible changes to the existing rule?

[JakeWharton]

You would still need 4 on the classpath because it's a super type so what's
the advantage of doing that?

On Wed, Feb 27, 2019, 3:13 PM Florent Biville <[email protected]
wrote:

but essentially wouldn't need to be a part of the core project either

Not sure I am following: by core project, do you mean OkHttp or
MockWebServer?

Given JUnit 4 and 5 can be both in the classpath afaik, what about adding
JUnit 5 to MockWebServer and introducing a new class like
MockWebServer(JUnit5)Extension without introducing visible changes to the
existing rule?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/square/okhttp/issues/4667#issuecomment-468012912, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEEEeTOy8c4CvY674sY2ieUwvoBzNEBks5vRub3gaJpZM4bUX4X
.

[swankjesse]

Also – we should assume there will be another incompatible library called JUnit 6 in a few years.

[JakeWharton]

Yeah we need to just break this in OkHttp 4 and decouple the need for a
server from the idea that you're inside a test runner.

On Sat, Mar 2, 2019, 3:39 PM Jesse Wilson <[email protected] wrote:

Also – we should assume there will be another incompatible library called
JUnit 6 in a few years.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/square/okhttp/issues/4667#issuecomment-468958019, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEEEboweT8OBwWc_PSnR0K4-hGQiqn0ks5vSuGWgaJpZM4bUX4X
.

[ati90ati]

As I know Junit 5 supports Java 11.
It will be a good idea to decouple and to rely only on the Junit 5, so we don't need to have the Junit 4 dependency with Junit 5 dependencies on the classpath because the MockWebServer dependency.

[pyricau]

👋 just dumping a note that this is causing https://github.com/square/leakcanary/issues/1649

[tokuhirom]

I'm migrating my project to junit5 and found this issue. And, I guess org.junit.jupiter:junit-jupiter-migrationsupport may not help me. Since org.junit.rules.ExternalResource is not included in junit-jupiter-migration-support.
If a user wants to use a mockwebserver with junit5, the user needs to add junit:junit in the dependency tree.

[yschimke]

MockWebserver probably isn't considered a top priority public API compared to the client, and upgrading this is awkward. Best fix is probably a lift and shift and API refactor under a different square project.

[wbervoets]

is a different square project for it planned?

MockWebserver probably isn't considered a top level public API, and upgrading this is awkward. Best fix is probably a lift and shift and API refactor under a different square project.

[yschimke]

~I don't speak for anyone at Square. But having modules in okhttp like okhttp-mockwebserver-core, okhttp-mockwebserver-junit4, okhttp-mockwebserver-junit5, okhttp-mockwebserver-testng doesn't sound viable.~

[tokuhirom]

I proposed another approach to this issue, how do you think this? https://github.com/square/okhttp/pull/6192 @yschimke

[yschimke]

The split seems interesting, do you think it's generally API/binary compatible?