Skip to content

Preserve CharSequence assertions in sequenced collections - #1095

Open
martinfrancois wants to merge 2 commits into
openrewrite:mainfrom
martinfrancois:agent/repro-simplify-sequenced-string-assertion
Open

Preserve CharSequence assertions in sequenced collections#1095
martinfrancois wants to merge 2 commits into
openrewrite:mainfrom
martinfrancois:agent/repro-simplify-sequenced-string-assertion

Conversation

@martinfrancois

@martinfrancois martinfrancois commented Aug 15, 2026

Copy link
Copy Markdown
Contributor

Suggested review order: 20 of 52 (Score: 6.5)
Review first: #1094

What's changed?

Leaves a sequenced-collection assertion unchanged when the selected element uses a CharSequence-specific AssertJ assertion. Assertions supported by the generic element assertion continue to use .first() or .last().

What's your motivation?

Recipe: org.openrewrite.java.testing.assertj.SimplifySequencedCollectionAssertions.

I found this by running org.openrewrite.java.testing.assertj.SimplifySequencedCollectionAssertions from org.openrewrite.recipe:rewrite-testing-frameworks:3.42.0 on TrelloClientTest.java in Symphony-Trello at a8013f27. I reproduced the same result with the latest released recipe artifact, org.openrewrite.recipe:rewrite-testing-frameworks:3.44.0. ./mvnw -DskipTests test-compile then fails because .first() returns ObjectAssert<String>, which has no startsWith(String) method.

Before

assertThat(readRequests.getFirst())
        .startsWith("GET /1/boards/board-1/cards/open?")
        .contains("fields=")
        .doesNotContain("actions=");

Actual after the recipe

assertThat(readRequests).first()
        .startsWith("GET /1/boards/board-1/cards/open?")
        .contains("fields=")
        .doesNotContain("actions=");

Expected after the recipe

(unchanged)

The rewrite changes the AssertJ assertion type from a string assertion to a generic object assertion. The fluent string methods are then unavailable, so the transformed target does not compile.

Confirmed real-world execution

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

Please review the assertion-chain scan and the distinction between generic equality assertions and CharSequence-specific operations.

Have you considered any alternatives or workarounds?

Adding another AssertJ narrowing operation would make the result more complex than the original. Leaving this chain unchanged is both shorter and type-safe.

Any additional context

Pre-existing tests changed: SimplifySequencedCollectionAssertionsTest.java.withDifferentAssertions (updated).

This change was prepared with AI assistance. I reviewed the target execution evidence, implementation, tests, and contribution text.

Checklist

@github-project-automation github-project-automation Bot moved this to In Progress in OpenRewrite Aug 15, 2026
@martinfrancois
martinfrancois force-pushed the agent/repro-simplify-sequenced-string-assertion branch from 4f9ed39 to fcd7c01 Compare August 15, 2026 23:04
@martinfrancois martinfrancois changed the title Retain element-specific AssertJ types for sequenced collections Preserve CharSequence assertions in sequenced collections Aug 15, 2026
@martinfrancois
martinfrancois force-pushed the agent/repro-simplify-sequenced-string-assertion branch from fcd7c01 to 1dd7ed3 Compare August 16, 2026 02:53
@martinfrancois
martinfrancois marked this pull request as ready for review August 17, 2026 08:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

1 participant