Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AssertJ assertions not collapsed on Integer #604

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

timo-abele
Copy link
Contributor

@timo-abele timo-abele commented Sep 21, 2024

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

@timo-abele timo-abele changed the title demo: add test see if build fails [DRAFT] demo: add test see if build fails Sep 21, 2024
@timtebeek timtebeek marked this pull request as draft September 21, 2024 08:16
@timtebeek timtebeek changed the title [DRAFT] demo: add test see if build fails AssertJ assertions not collapsed on Integer Sep 21, 2024
@timtebeek
Copy link
Contributor

timtebeek commented Sep 21, 2024

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

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 }>

Copy link
Contributor

@timtebeek timtebeek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

…secutiveAssertThatStatementsTest.java

Co-authored-by: Tim te Beek <[email protected]>
@timtebeek timtebeek added the bug Something isn't working label Sep 21, 2024
timo-abele and others added 2 commits September 21, 2024 10:30
…secutiveAssertThatStatementsTest.java

Co-authored-by: Tim te Beek <[email protected]>
…secutiveAssertThatStatementsTest.java

Co-authored-by: Tim te Beek <[email protected]>
@timtebeek
Copy link
Contributor

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 timtebeek added enhancement New feature or request and removed bug Something isn't working labels Sep 21, 2024
@timo-abele timo-abele removed their assignment Sep 21, 2024
@timtebeek
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: In Progress
Development

Successfully merging this pull request may close these issues.

2 participants