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.
Describe the bug
#3617 has introduced a regression in
StandardRepresentationwhen handling anUnquotedString.UnquotedStringimplementsCharSequenceso it's now handled as such. This results in it being wrapped in quotes.Test case reproducing the bug
A possible workaround is to implement a custom
QuotedStringclass that doesn't implementCharSequenceso thatStandardRepresentationthen falls back to callingtoString():Is this a reasonable approach? I'm wondering if the loss of the various
CharSequencemethods or the lack of hashCode and equals may cause problems.