GenericContainer run from Jupiter tests shouldn't require JUnit 4.x library on runtime classpath #970
Comments
|
Hi @bmuschko, We very much agree, and we do plan to remove the dependency, but it will be a breaking change and we will do it in Testcontainers 2.0. |
|
Also see #87 with some more (historic) discussions regarding this topic. |
|
Great, thanks for confirming. Looking forward to 2.0. |
|
I ran into this issue as well and it's currently a blocker for me. Is there any estimated date when 2.0 will be released? Where can I find roadmap? The product looks very promising btw :) looking forward to 2.0 as well so I can finally start using it |
|
Sorry, we haven't updated the roadmap for quite some time 🙂 |
|
wow, that was a quick response :) |
|
I see, makes sense for some projects. |
|
Any updates on this one? |
|
@evonier no updates since the last acknowledgement of the problem and the promise to target it for 2.x version. |
|
Updating testcontainers from version 1.11.4 to version 1.12.0 fixed the same problem for me |
But things still derive from the JUnit 4 |
|
Is there any update ? With v 1.12.5 the exclusion of junit dependency still results in class problems. As a hint: at my work, I use a test container jdbc url for creating the datasource. And therefore, the docker container "run" creation is delegated to the test container driver itself. No explicit coding with |
You can create your wrapper maven project, exclude JUnit4 and provide necessary JUnit classes separately. |
|
Here's a workaround if no dependency on JUnit 4 is a must: create fake and |
|
@detouched Was getting the following exception: |
|
Is there any intention to fix this in the near future?
Same here 👍 We also excluded all JUnit 4 dependencies to be forced to use Jupiter. |
|
@pixelstuermer since this is not a major issue, atm we're focusing on other, bigger ones. That said, we do plan to decouple the core from JUnit 4 in 2.0 (with probably an experimental API in 1.x that will allow the migration path), but it will take a bit of time. |
OK thanks. Nice to hear that you will keep an eye on this 👍 |
While above is a bit harsh, it is really regrettable that 5 years since there is absolutely no progress on this issue. |
As a hack to work around testcontainers/testcontainers-java#970, we add these fake, empty classes. Copied from Spring project. See also: testcontainers/testcontainers-java#970
|
:( Another release of testcontainers, and yet it's not 2.0 :( :( |
|
For reference, this has become an issue in the project I'm working on. Somehow, IntelliJ is picking up that the project has junit4 on the class path (?) and tries to load the
The workaround in my case was to add Upstream IntelliJ issue: https://youtrack.jetbrains.com/issue/IDEA-233706/Failed-to-resolve-junit-vintage-engine-4.12.9-when-trying-to-run-JUnit-5-test#focus=Comments-27-8188989.0-0 |
|
Wish this could be resolved, testcontainers is the only part still pulling in Junit4 for us, it would be nice not having to tell junior developers anymore that half the test related annotations IntelliJ provides should not be used. |
|
@void-spark If using Gradle, you can save your junior developers from themselves with configurations.all {
resolutionStrategy.dependencySubstitution {
substitute(module("junit:junit"))
.using(module("io.quarkus:quarkus-junit4-mock:3.0.0.Final"))
.because(
"We don't want JUnit 4; but is an unneeded transitive of testcontainers. " +
"See https://github.com/testcontainers/testcontainers-java/issues/970"
)
}
}Which will yield Since the "mock" doesn't contain all the common annotations/classes like And if you're worried about what's in it, can check out https://github.com/quarkusio/quarkus/tree/main/core/junit4-mock |
|
Ugh. That's such an ugly hack :) See https://stackoverflow.com/questions/61629824/preventing-the-use-of-junit4-libraries-in-a-project for some good answers |
In one way yes, but the nice part about the hack is that you don't even get |
|
That may compile but doesn’t actually work. |
|
Nope, still no 2.0, any timelines yet? :) |
|
It's April 2024. It's time for 2.0 to fix this issue.This was opened in 2018, 6 years ago. Do you remember those days? No AI back then. No python. (oh wait, there was Python) |
|
We also encountered this problem in our projects. We couldn't find any junit4-mock dependency specifically for Testcontainers (besides the mock for quarkus mentioned above) so we simply wrote our own. |
|
This is one of the things that always will be with us I think, I can not image how many times I bumped into something "junit4 vs junit5" - go solve your dependencies. It's been 7 years since Junit5 was released but the ghost will be us for a long time. Let's get rid from 4, legacy will be legacy |
|
I have to admit that I find it very surprising that this has not been addressed since Nov 2018 in a project with the impact, reach, success and motivation like Testcontainers. |
|
Seems the only working solution for projects working with Testcontainers and disallowing Junit4 to guarantee that developers won't use junit4 in their tests is to use IllegalImport check of CheckStyle (https://checkstyle.org/checks/imports/illegalimport.html) and ban both junit4 specific packages:
and separately specific classes:
|
|
In my case I opted by excluding all JUnit 4 dependencies and copy some of those required interfaces in the test sources. Definitely I don't love it, but it seemed to me this was the best approach to ensure we only work with JUnit 5. 
|
|
Any update on this ? |
|
We (i.e. @eddumelendez) did some preliminary work for this, but already switching to a new internal API (which is already in use(, that will eventually become the new public API and will be JUnit4 free. However, as of today, we can't give an ETA and it is not on our short-term roadmap. |
and others
I tried out the JUnit 5 support using the following build script. I'd expect that TestContainers doesn't require the JUnit 4.x library. As you can see in the build script below, the legacy dependency has been excluded.
In my test case, I am creating a
GenericContainer.At runtime I get the following exception. My guess is that
GenericContainerstill uses JUnit 4.x classes.The text was updated successfully, but these errors were encountered: