DBRider support

[Jenson3210]

What problem are you trying to solve?

Internally, we're using dbrider for integration test that assert db state. It's an extension on top of dbunit that allows for csv datasource annotations on top of test cases.
Between junit4 and 5, there are some changes to the usage.
We could try and create support for this.

Describe the situation before applying the recipe

@AutoConfigureMockMvc
@ActiveProfiles(INTEGRATION_TEST)
@SpringBootTest
@TestExecutionListeners(mergeMode = TestExecutionListeners.MergeMode.MERGE_WITH_DEFAULTS, listeners = {DBRiderTestExecutionListener.class})
@DBUnit(mergeDataSets = true, mergingStrategy = DataSetMergingStrategy.CLASS)
@DataSet(cleanBefore = true, cleanAfter = true, value = "")
public abstract class AbstractIntegrationTest {
    ...
}

Describe the situation after applying the recipe

@AutoConfigureMockMvc
@ActiveProfiles(INTEGRATION_TEST)
@SpringBootTest
@DBRider
@DBUnit(mergeDataSets = true, mergingStrategy = DataSetMergingStrategy.CLASS)
@DataSet(cleanBefore = true, cleanAfter = true, value = "")
public abstract class AbstractIntegrationTest {
    ...
}

Have you considered any alternatives or workarounds?

Manual changes? 🤢

Any additional context

see docs on dbrider here

Are you interested in contributing this recipe to OpenRewrite?

I will try to come up with certain aspects, but additional support is always welcome as this is completely greenfielded topic from open rewrite perspective.

[timtebeek]

Reading between the lines it looks like you'll have to match @TestExecutionListeners, remove that, and replace it with @DBRider; correct? I see @DBRider can have arguments, but none that come from the old annotation I suppose, making this a fairly straightforward visitor. You can then combine the recipe you'll create with some declarative recipes to bump to the next minor or patch version, just so there's a single recipe we can hook into a JUnit 4 to 5 upgrade.

[Jenson3210]

yes, that's indeed what is the case here...

Only thing. I only want to remove the specific listener and then remove the annotation if no listeners remain.
If there is another listener also, that should be a different recipe.

[Jenson3210]

@timtebeek
I started on an implementation (see branch)

I am facing 3 issues which I do not understand/do not know how I could start solving:

• doNotTouchIfDbRiderAlreadyPresent and removeListenerFromOtherListeners -> LST contains missing or invalid type information
  
  All others tests start from a very similar setup, yet these do not have MissingTypeInformation errors.
• Based on AddConfigurationAnnotationIfBeansPresent, I added similar logic in my recipe. However, I am seeing the annotation being added without Prefix/space.
  
• I have an annotation with arguments that are like @Annotation(arg1="...", arg2="..."). If I remove arg1, arg 2 keeps the space it has. I could add a visit override that looks at all arguments and formats them. But if the project is configuring @annotation( arg1="...", arg2="..." )`, removing these spaces would break "their style". I am sure core will contain one or another nifty trick to do this that I do not know (yet).
  

[Jenson3210]

The spaces issues where both fixed with Prefix-workarounds
The lst information was fixed by cleaning the imports in the test case