Validate actual rule object instead of Field#type for @Rule #1720
Comments
|
It seems like the only reason: TestRule can be created by.a method, so such a check covers both. |
|
What if the failure was delayed till the execution time? |
|
It's possible to implement it differently, the question is if it's worth modifying old behaviour in a project which is not actively developed at the moment (kind of maintenance mode). Practically, It would be better designing it differently in testcontainers. |
|
It doesn't sound like changing JUnit's behavior in this way would resolve all (most?) of the issues that your customers are complaining about, since some of them don't want JUnit 4 x classes on the classpath at all. Since you need to make a breaking change anyway, have you considered releasing two jars, one that provides extensions compatible with JUnit 5 and the other providing Rule versions of those extensions? |
|
The typical Java approach is to have an interface and multiple implementations: junit4, junit5. The problem is that junit4 forces interface to extend junit4-related class, so it forbids the idea of having a common api for the clients. I am not sure if that is the only issue, however, it does look like junit4 issue to me |
|
From JUnit's perspective, the interface is You can still have a common interface for your users. Your JUnit4 implementation would implement your interface and While it may be possible to resolve this issue the way you want, your users would have to wait for a JUnit 4 x release, and feature development for JUnit4 is presently frozen. |
|
Does JUnit have a separate API-only jar so TestRule "API" can be used without bringing full JUnit to the classpath and without clients having multiple @test annotations? |
|
JUnit4 does not have API jars. If people want to prevent use of JUnit 4 annotations in their tests, I'm guessing they could write an ErrorProne rule to check for that. |
That is why it is really sad to suppose that
Users would have to configure IDE manually to avoid suggesting |
|
The others on this thread are simply trying to suggest alternative solutions. Feature development for JUnit4 is presently frozen (as the maintainers that remain are focusing their efforts on JUnit 5) so currently the likelihood to get your proposed change implemented and released is low. That's not to say it wouldn't happen (and a pull request with a fix including tests may change some minds) but it's probably best for you to consider alternative solutions that don't involve a new release of JUnit 4.x. I suggest exploring the ideas in #1720 (comment) or #1720 (comment) (or at least commenting on why those approaches are fundamentally unworkable). |
|
@kcooney , the fix at junit4 side is trivial (see #1721), and the "solutions" of shading junit4 or making extra artifacts would be non-trivial, especially when it comes to licensing and build configuration. In fact, the users should never call Just in case, I perfectly understand junit4 is dormant, however, the fix seems to be trivial, it breaks no tests (there are tests that expect |
|
it's slightly more involved, as exceptions should be thrown before or after that. |
I'm not convinced that is the case. Couldn't Testcontainers use its own interface (e.g. |
|
@marcphilipp that's exactly the purpose of the issue - currently JUnit 4 requires that the rule fields / methods should be declared with a type which extends |
|
One of the sad consequences of |
|
@panchenko What I meant was sth. along these lines: JUnit 4public class SomeTests {
@Rule TestRule rule = new TestcontainersRule();
Network network = new Network();
GenericContainer container = new GenericContainer(...);
@Test public void test() { ... }
}JUnit Jupiter@ExtendWith(TestcontainersExtension.class)
public class SomeTests {
Network network = new Network();
GenericContainer container = new GenericContainer(...);
@Test public void test() { ... }
} |
|
Would be easier to implement if passing containers to the rule/extension constructor: Network network = new Network();
GenericContainer container = new GenericContainer(...);
@RegisterExtension
TestcontainersExtension extension = new TestcontainersExtension(network, container);Slightly more code to write, also a breaking change, but looks good. |
@Rule TestRule rule = new TestcontainersRule();^^ This is sad because uses might try calling methods on |
I raised that concern back when Having rule classes directly implement |
|
@marcphilipp There are indeed plans to remove the dependency to JUnit4 from the core of Testcontainers and bring JUnit4 support into a module, similar to how we do it for JUnit5 or Spock. That being said, we currently don't have an ETA for this, since it is a slightly more involved and potentially breaking change on our side, while ultimately not bringing any new functionality. For the time being, I'd suggest reconsidering if having JUnit4 on the classpath is a fundamental problem after all. |
Currently, JUnit validates field's type, and it wants the declaration to implement
TestRule.Is there a reason for that? What if JUnit4 validated the actual value rather than field type?
The validation makes it harder to implement code that supports both JUnit4 and JUnit5.
Sample issue: testcontainers/testcontainers-java#970 (/cc @bsideup, @baev)
TL;DR: Testcontainers has to implement junit4-specific interfaces in Testcontainers APIs, thus Testcontainers forces everybody to have JUnit4 on the classpath which is sad.
https://github.com/testcontainers/testcontainers-java/blob/aa273b5c0136d8bf8d9eb308040b30006ad98144/core/src/main/java/org/testcontainers/containers/Network.java#L20
However, if
Network extends TestRuleis replaced withNetworkImpl implements Network, TestRule, then JUnit4 fails as follows:See also #1020
The text was updated successfully, but these errors were encountered: