Visitar URL original
Unquoted string produced by BasicErrorMessageFactory is quoted by StandardRepresentation in 3.27.x · Issue #3733 · assertj/assertj · GitHub
Skip to content

Unquoted string produced by BasicErrorMessageFactory is quoted by StandardRepresentation in 3.27.x #3733

Description

@wilkinsona

Describe the bug

#3617 has introduced a regression in StandardRepresentation when handling an UnquotedString. UnquotedString implements CharSequence so it's now handled as such. This results in it being wrapped in quotes.

  • assertj core version: 3.27.x
  • java version: Any
  • test framework version: N/A
  • os (if relevant): N/A

Test case reproducing the bug

@Test
void hasNotFailedWhenFailedShouldFail() {
	assertThat(new TestErrorMessageFactory().create()).isEqualTo("alpha \"bravo\"");
}

static class TestErrorMessageFactory extends BasicErrorMessageFactory {

	public TestErrorMessageFactory() {
		super("%s %s", unquotedString("alpha"), "bravo");
	}

}

A possible workaround is to implement a custom QuotedString class that doesn't implement CharSequence so that StandardRepresentation then falls back to calling toString():

static class TestErrorMessageFactory extends BasicErrorMessageFactory {

public TestErrorMessageFactory() {
	super("%s %s", new UnquotedString("alpha"), "bravo");
}

private static class UnquotedString {

	private final String string;

	private UnquotedString(String string) {
		this.string = string;
	}

	@Override
	public String toString() {
		return this.string;
	}

}

Is this a reasonable approach? I'm wondering if the loss of the various CharSequence methods or the lack of hashCode and equals may cause problems.

Activity

  1. added this to the 3.27.3 milestone on Jan 8, 2025
  2. joel-costigliola commented on Jan 8, 2025

    @joel-costigliola
    Member

    Good catch thanks @wilkinsona

  3. added a commit that references this issue on Jan 8, 2025
    beeed8c
  4. scordio commented on Jan 17, 2025

    @scordio
    Member

    I'm wondering if the loss of the various CharSequence methods or the lack of hashCode and equals may cause problems.

    I think that would be a breaking change for unquotedString(String) which is exposed to the subtypes of BasicErrorMessageFactory, so it's probably safer to go with the approach of #3735.

  5. wilkinsona commented on Jan 17, 2025

    @wilkinsona
    ContributorAuthor

    Thanks, @scordio. Sorry, I wasn't clear earlier. I was wondering about a workaround that would allow 3.27.2 to be used without strings becoming quoted. I wasn't suggesting a fix for AssertJ itself.

  6. scordio commented on Jan 18, 2025

    @scordio
    Member

    Fixed in f308d95, forward ported in ede5feb.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions