JMockit to Mockito Migration Recipe - Rewrite Expectations Block

[tinder-dthomson]

What's changed?

• Added a new recipe ExpectationsToMockito to handle converting a JMockit Expectations block to a Mockito when statement. (WIP)
• Added declarative recipe org.openrewrite.java.testing.jmockit.JMockitToMockito, to eventually list all the recipes necessary for the migration.
• Added a unit test JMockitToMockitoTest for testing the declarative recipe.

What's your motivation?

Work towards a full JMockit to Mockito migration recipe. This migration is quite involved for large codebases, and JMockit presents challenges for migrating to Java 17.

Checklist

• I've added unit tests to cover both positive and negative cases
• I've added the license header to any new files through ./gradlew licenseFormat
• I've used the IntelliJ IDEA auto-formatter on affected files

[SimonVerhoeven]

I noticed the recipes were located in the Mockito package, maybe it would be better to create a JMockit one since it's migration related to be in line with https://github.com/openrewrite/rewrite-testing-frameworks/tree/main/src/main/java/org/openrewrite/java/testing/hamcrest?

[kunli2]

Hi Devin, Thanks for your contribution!
I updated the code and it can pass the test now, the only thing I am not quite sure about is why the when() from the template does not have a method type.

[tinder-dthomson]

Hi Devin, Thanks for your contribution! I updated the code and it can pass the test now, the only thing I am not quite sure about is why the when() from the template does not have a method type.

Thank you so much! Do you mind explaining your changes a bit?

From what I saw, your changes can be broken into three categories:

• Classpath Updates
• Setting typeValidationOptions to TypeValidation.none() on the test spec parser
• Using newMethod.withPrefix(newClass.getPrefix()) (curious if nc.getPrefix() would have been okay too?)

I have the following specific questions:

• Were classpath updates you made were functionally necessary or simply a best practice? I couldn't tell why you added mockito-junit-jupiter-3.12 to the test parser classpath, for example.
• Would using nc.getPrefix() as the param to newMethod.withPrefix() be problematic? I would guess newClass and nc are the same pointer, unless calling super.visitNewClass clones it.

[kunli2]

Hi Devin, Thanks for your contribution! I updated the code and it can pass the test now, the only thing I am not quite sure about is why the when() from the template does not have a method type.

Thank you so much! Do you mind explaining your changes a bit?

From what I saw, your changes can be broken into three categories:

• Classpath Updates
• Setting typeValidationOptions to TypeValidation.none() on the test spec parser
• Using newMethod.withPrefix(newClass.getPrefix()) (curious if nc.getPrefix() would have been okay too?)

I have the following specific questions:

• Were classpath updates you made were functionally necessary or simply a best practice? I couldn't tell why you added mockito-junit-jupiter-3.12 to the test parser classpath, for example.
• Would using nc.getPrefix() as the param to newMethod.withPrefix() be problematic? I would guess newClass and nc are the same pointer, unless calling super.visitNewClass clones it.

Adding those classpaths is to get type attributions, and we just need to add necessary minimum set of classpaths.
import org.mockito.junit.jupiter.MockitoExtension I think this import requires mockito-junit-jupiter-3.12.
Yeah, using nc.getPrefix() is better here, it's supposed to be supposed to be supported by autoFormat here, but replacing the prefix also works here.

[kunli2]

LGTM, thanks for your contribution again!