AssertJ assertions not collapsed on Integer

[timo-abele]

What's changed?

What's your motivation?

I expected the recipe to collapse assertThats on any type, but in my project it didn't work on an Integer.
This PR verifies my observations and serves as a starting point for #605

Anything in particular you'd like reviewers to focus on?

Anyone you would like to review specifically?

Have you considered any alternatives or workarounds?

Any additional context

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[timtebeek]

Hi @timo-abele ! Thanks for notifying us with a runnable test. :) It looks to fail on this particular line:

rewrite-testing-frameworks/src/main/java/org/openrewrite/java/testing/assertj/CollapseConsecutiveAssertThatStatements.java

Line 104 in 3412efb

return TypeUtils.isOfType(assertThat.getType(), assertion.getType());

method	type
assertThat.getType()	org.assertj.core.api.AbstractIntegerAssert<Generic{?}>
assertion.getType()	Generic{? extends org.assertj.core.api.AbstractIntegerAssert<Generic{? extends }>}
assertion.getType().getBounds().get(0)	org.assertj.core.api.AbstractIntegerAssert<Generic{? extends }>

[timtebeek]

Some minor suggestions to get the test going: there's no need to add the JUnit dependency here. :)

[timtebeek]

You'll notice that the types are different; we have that prevent methods like extracting from changing the type, as those can't be safely chained.

We can likely relax the type comparison a little though, to allow for parameterized types with a bound that includes the same class, even if the generic bound is slightly different (Generic{?} vs Generic{? extends })

[timtebeek]

Thanks for getting this started! We can keep this open until the moment we figure out the exact change needed to get this going, as indeed we're a little too conservative right now, not chaining all the cases we could potentially.