-
Notifications
You must be signed in to change notification settings - Fork 914
[JUnit 5] Migrate to JUnit 5 Platform (with existing JUnit 4 test cases) #2850
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
Merged
Bennett-Lynch
merged 9 commits into
aws:master
from
Bennett-Lynch:junit5-migration-step1
Nov 18, 2021
Merged
[JUnit 5] Migrate to JUnit 5 Platform (with existing JUnit 4 test cases) #2850
Bennett-Lynch
merged 9 commits into
aws:master
from
Bennett-Lynch:junit5-migration-step1
Nov 18, 2021
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
## Motivation We would like to leverage JUnit 5's concept of global hooks which can be installed and detected as part of the class path: https://junit.org/junit5/docs/current/user-guide/#extensions-registration-automatic However, our current codebase uses JUnit 4 almost everywhere, except for the stability tests, which leverage JUnit 5. Besides wishing to take advantage of newer features, there is additional value in making sure our tests are consistent and up-to-date as well. JUnit 5 offers the junit-vintage-engine module to support legacy JUnit 4 style tests. Simply having it available on the class path will allow JUnit 4 tests be executed with the JUnit 5 Platform launcher: https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4 JUnit 4 -> 5 migrations are often done in a 3-step process: 1. Update dependencies to JUnit 5, including the vintage module, causing all tests to leverage the new JUnit 5 Platform 2. Incrementally migrate JUnit 4 tests to JUnit 5 tests 3. Once no JUnit 4 usage remains, remove the dependency on the vintage module This commit achieves the first step in the above process, which will also allow us to immediately leverage JUnit 5-specific features, like global/classpath hooks. ## Modifications * Upgrade JUnit 5 version from 5.4.2 to 5.8.1 (latest) * For all existing usages of junit, replace them with a dependency on junit-jupiter and junit-vintage-engine
Kudos, SonarCloud Quality Gate passed!
|
joviegas
approved these changes
Nov 18, 2021
Bennett-Lynch
pushed a commit
to Bennett-Lynch/aws-sdk-java-v2
that referenced
this pull request
Nov 18, 2021
Bennett-Lynch
pushed a commit
to Bennett-Lynch/aws-sdk-java-v2
that referenced
this pull request
Nov 18, 2021
1 task
Bennett-Lynch
added a commit
that referenced
this pull request
Dec 2, 2021
JUnit 4 -> 5 migrations are often done in a 3-step process: 1. Update dependencies to JUnit 5, including the vintage module, causing all tests to leverage the new JUnit 5 Platform (completed in #2850) 2. Incrementally migrate JUnit 4 tests to JUnit 5 tests 3. Once no JUnit 4 usage remains, remove the dependency on the vintage module This PR begins step 2 by migrating tests which can be easily converted. IntelliJ provides a convenient way to migrate tests but unfortunately there is no support for automatically migrating JUnit 4 tests which leverage any of the following: 1. The `expected` parameter in test annotations 2. The `timeout` parameter in test annotations 3. The class-level `@RunWith` annotation (e.g., `@RunWith(Parameterized.class)` and `@RunWith(MockitoJUnitRunner.class)`) Therefore, this PR leverages the migrate functionality but defers the above scenarios as follows: ``` grep -r -e "@test(" -e "@RunWith(" . | cut -d ':' -f1 | xargs -I {} git restore {} ``` All changes in this PR are fully automated with the migrate functionality, except for the changes to the top-level pom.xml to add `org.junit.*` to both `ignoredUsedUndeclaredDependency` and `ignoredUnusedDeclaredDependency`. Additionally, there were a few cases of the migrate functionality migrating a superclass but not being able to migrate a subclass (due to the above limitations). The superclass was restored in this case.
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
We would like to leverage JUnit 5's concept of global hooks which can be
installed and detected as part of the class path:
https://junit.org/junit5/docs/current/user-guide/#extensions-registration-automatic
However, our current codebase uses JUnit 4 almost everywhere, except for
the stability tests, which leverage JUnit 5. Besides wishing to take
advantage of newer features, there is additional value in making sure
our tests are consistent and up-to-date as well.
JUnit 5 offers the junit-vintage-engine module to support legacy JUnit 4
style tests. Simply having it available on the class path will allow
JUnit 4 tests be executed with the JUnit 5 Platform launcher:
https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4
JUnit 4 -> 5 migrations are often done in a 3-step process:
all tests to leverage the new JUnit 5 Platform
module
This commit achieves the first step in the above process, which will
also allow us to immediately leverage JUnit 5-specific features, like
global/classpath hooks.
Modifications
junit-jupiter and junit-vintage-engine
which has better support for JUnit 5
https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html
License