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

• CollapseConsecutiveAssertThatStatements does not work on Integers (possibly only on Lists?) #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.

[timtebeek]

Explored this briefly again, but couldn't yet find an easy solution with the generics mismatch between the two method invocations. We'll merge this with the test disabled such that it's easier to pick up #605 in the future.