[Enhancement] Upgrade JUnit to JUnit Jupiter #4478
Labels
enhancement
New feature or request
Comments
|
Welcome to the Apache EventMesh community!! Please make sure to include all the relevant context. If you are interested in contributing to our project, please let us know! Want to get closer to the community?
Mailing Lists:
|
mxsm
pushed a commit
that referenced
this issue
Oct 10, 2023
* Fix JUnit dependecy issue in eventmesh-storage-kafka * Clean up JUnit dependency in eventmesh-protocol-grpc * Remove empty arguments to @test annotations Adding empty arguments adds no value, and will just interfere with future efforts to migrate to JUnit Jupiter. * Remove PowerMockito usages PowerMockito is known to be slow and cumbersome compared to Mockito. In most cases, removing it was a straight forward change of removing the PowerMockito annotations and use the MockitoJUnitRunner. In the single non-trivial case, WebHookProcessorTest, PowerMockito's WhiteBox was removed and replaced with Mockito's @Injectmocks annotation. * Clean up Mockito dependencies mockito-inline is intended to replace mockito-core in cerain situations (e.g., mocking static or final classes), and there's no need to have them both as dependencies in the same module. This patch cleans up these duplications and leaves a "slimmer" dependency tree with just the required mockito dependency in each module. * Remove unneeded "org.apache.rocketmq:rocketmq-test dependency * Migrate testing to JUnit Jupiter In its current form, the project has some JUnit 4 and some JUnit 5 (Jupiter) tests. This patch aims to align all the tests to a single modern framework, JUnit Jupiter, in order to make future development easier. As this patch is already pretty large as-is, it attempts to be non-opinionated and simply replace JUnit 4 calls with the closed JUnit Jupiter equivalents. Subsequent work may want to change some tests to take further advantage of JUnit Jupiter's features. This patch includes the following changes: 1. Gradle dependencies: a. All the dependencies under org.junit.jupiter were consolidated to use the single artifact org.junit.jupiter:junit-jupiter. b. The junit:junit dependency was removed in favor of org.junit.jupiter:junit-jupiter as mentioned in 1.a.. c. The org.mockito:mockito-junit-jupiter dependency was added to provide the integration with Mockito. d. The com.github.stefanbirkner:system-rules dependency was removed in favor of org.junit-pioneer:junit-pioneer that was used to provide the same functionality as mentioned in 2.i. 2. Annotations a. org.junit.jupiter.api.BeforeEach was used as a drop-in replacement for org.junit.Before. b. org.junit.jupiter.api.BeforeAll was used as a drop-in replacement for org.junit.BeforeClass. c. org.junit.jupiter.api.AfterEach was used as a drop-in replacement for org.junit.After. d. org.junit.jupiter.api.AfterAll was used as a drop-in replacement for org.junit.AfterClass. e. org.junit.jupiter.api.AfterEach was used as a drop-in replacement for org.junit.After. f. org.junit.jupiter.api.Disabled was used as a drop-in replacement for org.junit.Ignore. g. org.junit.jupiter.api.Test was used as a replacement for org.junit.Test, although with some caveats: 1. For the simple case with no arguments, org.junit.jupiter.api.Test was used as a drop-in replacement for org.junit.Test. 2. For the case where org.junit.Test was used with a timeout argument, a combination of org.junit.jupiter.api.Test and org.junit.jupiter.api.Timeout was used. 3. For the case where org.junit.Test was used with an expected argument, org.junit.jupiter.api.Test was used, but the assertion on the exception begin thrown is done explicitly in the test's code, see 3.e. below. h. org.junit.jupiter.api.extension.ExtendWith was used as a replacement for org.junit.runner.RunWith with an extension corresponding to the runner being replaced. a. org.mockito.junit.jupiter.MockitoExtension was used to provide the same functionality as org.mockito.junit.MockitoJUnitRunner. Since the extension is stricter than the runner, in some cases org.mockito.junit.jupiter.MockitoSettings was used to explicitly make the mocking more lenient. i. org.junitpioneer.jupiter.SetEnvironmentVariable was used in order to set environment variables in the tests instead of explicitly calling org.junit.contrib.java.lang.system.EnvironmentVariables in the test's body. As an added bonus, using this annotation also cleans up the changes to the environment variables when the test is over and prevents it from inadvertently effecting other tests. 3. Assertions a. org.junit.jupiter.api.Assertions was used as a drop-in replacement for org.junit.Assert for the case where the assertion was performed without a message. b. org.junit.jupiter.api.Assertions was used instead of org.junit.Assert in the cases where an assertion method was used with a message, but the argument were permuted to fit the new method's signature. c. org.junit.jupiter.api.Assertions does not have an equivalent of org.junit.Assert's assertThat method, but luckily it was only used in a few places, and always used the org.hamcrest.CoreMatchers.is matcher. These assertions were rewritten as straight-forward assertEquals assertions. c. org.junit.jupiter.api.Assertions does not have an equivalent of org.junit.Assert's assertThat method, but luckily it was only used in a few places, and always used the org.hamcrest.CoreMatchers.is matcher. These assertions were rewritten as straight-forward assertEquals assertions. d. org.junit.jupiter.api.Assertions does not have an equivalent of org.hamcrest.MatcherAssert's assertThat method, but luckily it was only used in a few places, and always used the org.hamcrest.CoreMatchers.is matcher. These assertions were rewritten as straight-forward assertEquals assertions. e. org.junit.jupiter.api.Assertions' assertThrows was used to assert an expected exception is throws instead of using org.junit.Test with the expected annotation. * Fix dependency check
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Search before asking
Enhancement Request
In its current form, the project has some JUnit 4 and some JUnit 5 (Jupiter) tests, which may be confusing and make it harder to contribute to the project.
Describe the solution you'd like
Align all the tests in the project to JUnit Jupiter, so tests can be written in the same fashion for every module.
Are you willing to submit PR?
Code of Conduct
The text was updated successfully, but these errors were encountered: