Truth seems to import JUnit 4, even on JUnit 5

[jbduncan]

It occurs to me that the core/ subproject's pom.xml imports JUnit 4 as a non-test dependency. I think this is fine for projects that use JUnit 4 and Truth together for testing, but I'm a little concerned that for projects using JUnit 5 it will cause JUnit 4 to be unnecessarily downloaded and depended upon.

Are there any plans to move any parts of Truth which depend on JUnit 4 APIs into their own extensions?

[cpovirk]

Unfortunately, the parts of Truth that depend on JUnit 4 are basically all "all of them," since we throw ComparisonFailure.

There are at least a couple approaches we could take here:

• Throw ComparisonFailure conditionally only if it's available at runtime.
• Adopt the opentest4j types once they're finalized.

Overall, I'm not too concerned about a dependency on JUnit 4 in Truth, since it's a test framework. But if it's causing people trouble, we should reconsider.

[dimo414]

Throwing ComparisonFailure only if it's already on the classpath would be a silent regression for users not using JUnit4, so (as you say, assuming it's not causing real trouble) I think waiting for opentest4j makes the most sense.

[kashike]

opentest4j 1.0.0 was released on September 10th.

[cpovirk]

Cool, thanks.

[Androbin]

Since #40 is merged, we can close this now.

[jbduncan]

@Androbin Sorry, I'm unclear on how #40 is related to this issue. Would you kindly clarify things for me?

[Androbin]

Oops, I meant cashapp/misk#40 😁

[cpovirk]

Oh, thanks for the link:

Until this is resolved, we should be careful to use the @org.junit.jupiter.api.Test annotation and not @org.junit.Test by mistake.

That's a good downside for us to keep in mind. Inside Google, I think we're pretty much resigned to having JUnit 4 on our classpath, and people haven't started using JUnit 5 much. But externally, things are different.

This is still something we could consider doing someday. It's just not at the top of the list currently.

[Androbin]

Isn't there a way to search & replace "en masse" across the codebase?
Or is this simply not feasible?

[cpovirk]

We can do search and replace. My fears are:

• Some people will be catching particular exception types, and their code will break. They ideally wouldn't be doing that, but we still have to clean them up inside Google, and others will have to fix it outside Google :\ Of course, the sooner we make the change, the better, so that the fallout is smaller.

• We'd need to get the opentest4j exceptions working under GWT and Android [update: all the way back to Ice Cream Sandwich] -- which is probably straightforward but sometimes turns out not to be.

• The opentest4j annotations still look possibly not officially finalized -- or maybe the docs just haven't been updated yet, since they're used in JUnit 5?

None of these are necessarily huge problems; there just didn't seem to be a big upside to eliminating the JUnit 4 dependency. The release of JUnit 5 may change that, and it calls attention to a larger problem with multiple @Test annotations.

[cpovirk]

Oh, and we should also check whether IDEs have begun supporting the opentest4j AssertionFailedError. I gather that they probably have, but I'd want to be sure. (e.g., I found this comment suggesting that IntelliJ has problems, but it seems hard to believe. I'd still want to verify.)

[childnode]

@Androbin

Isn't there a way to search & replace "en masse" across the codebase?
Or is this simply not feasible?

just have a look what the gradle guys do with their codebase: gradle/gradle#4116 << tl;dr: auto converting and running junit 4 tests with junit 5 platform both vintage and converted https://github.com/gradle/gradle/pull/4116/files#diff-a5945fda2451f7bab0e91c578e8e7f2eR49 ff

BUT: this is just done for the gradle tests itself and not intended to be used for other projects neither as production code

THIS truth one has other impacts, but if you ask me: just deprecate Junit 4 support and branch for Junit 5 ;)