Add quick fix for Map.get(key) isEqualTo/isNotEqualTo(value)

[asm0dey]

Wires a quick fix for the AssertJ chain simplifications targeting
Map.get(key): rewrites assertThat(map.get(k)).isEqualTo(v) to
assertThat(map).containsEntry(k, v), and the isNotEqualTo variant to
doesNotContainEntry. Adds the new ActualKeyExpectedQuickFix which
combines the inner-call argument with the predicate argument, plus
positive (Map, HashMap) and negative (non-Map .get) tests.

[sonar-review-alpha]

Summary

Adds a new quick fix for AssertJ chain simplifications targeting Map.get(key) calls. Rewrites assertThat(map.get(k)).isEqualTo(v) to assertThat(map).containsEntry(k, v) and the isNotEqualTo variant to doesNotContainEntry. Introduces ActualKeyExpectedQuickFix, which extracts both the inner-call argument (the key) and the predicate argument (the value) to construct the simplified assertion.

What reviewers should know

Key files to review:

• Look for the new ActualKeyExpectedQuickFix class alongside existing quick fix implementations like ActualExpectedInPredicateQuickFix and ActualExpectedInSubjectQuickFix in the AssertJ simplification quick fix file
• Check how the quick fix builder constructs text edits to combine arguments from both the subject call (map.get(k)) and the predicate (isEqualTo(v))

Testing:

• Review positive test cases for Map and HashMap types to ensure proper detection of Map receivers
• Verify negative test cases that correctly exclude non-Map .get() calls (e.g., Optional.get()) from triggering the quick fix
• Test both isEqualTo → containsEntry and isNotEqualTo → doesNotContainEntry transformations

Watch for:

• Edge cases where .get() is called on non-Map types (these should NOT trigger the fix)
• Correct span calculation when extracting both the key argument and value argument across separate method calls
• That the predicate argument name change is properly handled in the text edits

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[sonar-review-alpha]

The PR introduces two duplicate simplifier registrations in the index — both sandwiching the newly inserted MAP_GET entries — which is a clear sign of copy-paste error during insertion. The test fixture also carries a stale [[quickfixes=!]] annotation on the Map case that will break once the quick fix is wired in.

Note: the ActualKeyExpectedQuickFix class and the updated quick-fix wiring (changing msgWithActualCustom to use the new class) could not be confirmed in the available repository state, so reviewers should verify those additions are present and correct in the actual diff.

Note — the following observations could not be attached as inline comments:

• java-checks/src/main/java/org/sonar/java/checks/tests/AssertJChainSimplificationIndex.java:156: This line is a duplicate of line 154 — both register PATH_GET_PARENT_AND_PARENT_FILE → hasParentRaw in the IS_EQUAL_TO block. The MAP_GET entry was inserted between them, but the trailing copy was not removed. The second occurrence is dead code because findFirst() in checkPredicatesForSimplification will always match line 154 first.

Remove this line.

• java-checks/src/main/java/org/sonar/java/checks/tests/AssertJChainSimplificationIndex.java:199: This line is a duplicate of line 197 — both register TRIM / isEmptyString → isNotBlank in the IS_NOT_EQUAL_TO block. Same pattern as the hasParentRaw duplicate: the MAP_GET entry was inserted between two copies of what should have been a single entry. The second occurrence is dead code.

Remove this line.

• java-checks-test-sources/default/src/test/java/checks/tests/AssertJChainSimplificationCheckTest_QuickFix.java:109: This line currently asserts [[quickfixes=!]] — i.e., that no quick fix is available for the Map.get case. Once ActualKeyExpectedQuickFix is wired in, this test will fail because a quick fix will be offered.

This line must be updated (or moved to the new Map-specific quick-fix fixture) to assert the expected fix@ and edit@ annotations for the containsEntry rewrite. Leaving it as-is will cause the test suite to fail.

🗣️ Give feedback

[asm0dey]

@NoemieBenard hey, I'm sorry, I'm not sure what happened here — somehow there are 0 changes in my PR, should I create a new one with the fixes requested?