Skip to content
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

Merged
merged 13 commits into from
Nov 22, 2023
Merged

Conversation

octonato
Copy link
Member

Experiment to support JUnit5

@github-actions github-actions bot added java-sdk-protobuf kalix-runtime Runtime and SDKs sub-team labels Nov 21, 2023
@octonato octonato changed the title Octonato/move to junit5 feat: support junit5 in Java Protobuf SDK Nov 21, 2023
Copy link
Member Author

@octonato octonato left a 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.

@@ -60,7 +63,7 @@
* }
* </pre>
*/
public final class KalixTestKitResource extends ExternalResource {
public final class KalixTestKitResource extends ExternalResource implements BeforeAllCallback, AfterAllCallback {
Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member Author

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
Copy link
Member Author

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.

@ennru
Copy link
Member

ennru commented Nov 21, 2023

@octonato octonato force-pushed the octonato/move-to-junit5 branch from 6df437b to 64cc959 Compare November 21, 2023 16:22
@octonato octonato marked this pull request as ready for review November 21, 2023 16:22
Comment on lines -128 to -129
junit4 % Provided,
junit5 % Provided,
Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Member

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.

Copy link
Contributor

@aludwiko aludwiko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@octonato octonato merged commit 321435e into main Nov 22, 2023
65 checks passed
@octonato octonato deleted the octonato/move-to-junit5 branch November 22, 2023 14:25
Comment on lines -128 to -129
junit4 % Provided,
junit5 % Provided,
Copy link
Member

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;
Copy link
Member

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?

Copy link
Member Author

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 {
Copy link
Member

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
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants