-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: support junit5 in Java Protobuf SDK #1876
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ennru, here is the results of first experiments.
I modified only one sample. The integration tests are using junit5, but the unit tests are still on junit4. It works with both if we add the vintage engine.
We can add support for junit5 and still support junit4 at the same time.
Newly generated test classes will be on junit5 though. Users really willing to stick with junit4 will have to change the generated tests.
samples/java-protobuf-customer-registry-kafka-quickstart/pom.xml
Outdated
Show resolved
Hide resolved
@@ -60,7 +63,7 @@ | |||
* } | |||
* </pre> | |||
*/ | |||
public final class KalixTestKitResource extends ExternalResource { | |||
public final class KalixTestKitResource extends ExternalResource implements BeforeAllCallback, AfterAllCallback { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When implementing this two interfaces (BeforeAllCallback
and AfterAllCallback
), we can use this class as a Registered Extension. Junit will take care of the lifecycle for us. This is the equivalent of ClassRule
in junit4.
KalixTestKitResource
has already a hard dependency on junit4. In the sbt project, junit4 is marked as provided and then we add it to the pom explicitly.
With this change, the KalixTestKitResource
will also depend on junit5 and we will need both in the pom. That's problematic for existing projects. If a user update the SDK version, but doesn't touch the pom, they will get an error.
Therefore, as mentioned above, we can solve it by added junit libraries as transitive dependencies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be an option to have a the JUnit 5 variant of this in the jupiter
package?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, that could be an option.
That will make it easier for us to deprecate junit4 support.
I will PR this.
@@ -38,7 +38,7 @@ public class CustomerActionWithKafkaIntegrationTest { | |||
/** | |||
* The test kit starts both the service container and the Kalix proxy. | |||
*/ | |||
@ClassRule | |||
@RegisterExtension |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will behave as the ClassRule
annotation if the class (ie KalixTestKitResource
) implements BeforeAllCallback
and AfterAllCallback
.
f1a6284
to
5862de3
Compare
Possibly interesting changes in Testcontainers v1.18.0: See even Testcontainers container lifecycle management using JUnit 5 |
6df437b
to
64cc959
Compare
junit4 % Provided, | ||
junit5 % Provided, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the most impactful change.
So far, our testkit was depending directly on a class from junit4. It has junit5 as dependency, but it was not used.
Users were required to have junit4 in their pom because it was Provided
.
It's annoying now to keep them as Provided
because the testkit now requires both libraries. That means that users will need to add both to their pom.xml.
By making them transitive through the testkit, we ensure that users will have both and can pick the one they prefer.
On our side, new projects (created from mvn archetype) and new generated code will use junit5.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see any point in supporting both junit versions. JUnit 5 was released in 2017. We could support both for a short transition time, but we should be very clear that migration is indispensable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even the current version of Testcontainers 1.19.3 depends on JUnit 4.13.2.
sdk/java-sdk-spring/src/it/java/com/example/wiring/tracing/TracingIntegratonTest.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
junit4 % Provided, | ||
junit5 % Provided, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even the current version of Testcontainers 1.19.3 depends on JUnit 4.13.2.
@@ -0,0 +1,33 @@ | |||
package com.example; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you intend to check in this and the others generated files under java-protobuf-doc-snippets
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, that was a mistake. And I'm surprised that they are not checked in. But I get why. We only build it to verify correctness and then the generated classed are each time recreated.
At some point, when chasing for compilation errors, I wrote a script to compile all projects under samples. That's how those got generated on my machine.
I will revert it.
@@ -60,7 +63,7 @@ | |||
* } | |||
* </pre> | |||
*/ | |||
public final class KalixTestKitResource extends ExternalResource { | |||
public final class KalixTestKitResource extends ExternalResource implements BeforeAllCallback, AfterAllCallback { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be an option to have a the JUnit 5 variant of this in the jupiter
package?
public void setUp() { | ||
closeable = MockitoAnnotations.openMocks(this); | ||
} | ||
|
||
@Before |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the record, that was my WTF moment of the day.
I don't know how this was working before, but the tearDown
method should be annotated with After
, not Before
.
What I'm guessing is that Junit4 will only run the first method it finds annotated with Before
. And the tearDown
where never called.
Experiment to support JUnit5