Skip to content

[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
merged 9 commits into from
Nov 18, 2021

Conversation

Bennett-Lynch
Copy link
Contributor

@Bennett-Lynch Bennett-Lynch commented Nov 17, 2021

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
  • Upgrade Maven Surefire version from 2.22.2 to 3.0.0-M5,
    which has better support for JUnit 5

https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html

License

  • I confirm that this pull request can be released under the Apache 2 license

## 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
@Bennett-Lynch Bennett-Lynch requested a review from a team as a code owner November 17, 2021 02:20
@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@Bennett-Lynch Bennett-Lynch merged commit 15e0755 into aws:master 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 added a commit 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
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants