Introduce assertThatCharSequence to disambiguate Groovy's GString

[scordio]

Feature summary

Currently, Groovy's interpolated expressions cannot be a direct input of assertThat as groovy.lang.GString implements both Comparable and CharSequence.

We might add assertThatCharSequence(CharSequence) / assumeThatCharSequence(CharSequence) and the corresponding BDD variants to disambiguate these calls.

Example

This should compile:

  @Test
  void should_accept_interpolated_expressions() {
    // GIVEN
    def foo = "foo"
    def actual = /.*${foo}.*/
    // WHEN/THEN
    assertThatCharSequence(actual).isEqualTo(".*foo.*")
  }

Implementation notes:

• The implementation can delegate to the existing assertThat(CharSequence)
• The new method should also be added to Java6 classes whenever possible. Assertions_sync and Java6Assertions_sync can help figure out where the gaps are.

Workaround

Use toString:

  @Test
  void should_accept_interpolated_expressions() {
    // GIVEN
    def foo = "foo"
    def actual = /.*${foo}.*/
    // WHEN/THEN
    assertThat(actual.toString()).isEqualTo(".*foo.*")
  }

[techrajdeep]

Hey @scordio, I am looking for an issue for my first contribution . Can you help me here. Can I take on this .

[scordio]

Hi @techrajdeep, sure, this issue is up for grabs. Anything where you'd need clarification?

[techrajdeep]

@scordio Could you please assign it to me

[debanjanc01]

Hey @scordio! Has this issue been fixed? I don't see a PR for it. If this is still up for grabs, I'd like to work on this.

[scordio]

Sure and thank you, @debanjanc01!

[debanjanc01]

Hey @scordio is there an existing test case that tests this out as you have mentioned in the example for should_accept_interpolated_expressions? Or shall I add the test case to Assertions_assertThat_with_Groovy_strings_Test.groovy?

[debanjanc01]

Hey @scordio, the problem with groovy.lang.GString is the way it implements the equals(Object) method. It expects that the other object is also an instance of groovy.lang.GString.

In the test case mentioned, assertThatCharSequence(actual).isEqualTo(".*foo.*") will lead to assertion of groovy.lang.GString against java.lang.String. On delegating to the existing assertThat(CharSequence) this would fail as internally CharSequenceAssert#isEqualTo(Object) would call StandardComparisonStrategy#areEqual(Object, Object).

I wanted to know if you have any suggestions to take this forward. This is to understand your preferences and weigh out the different options before proceeding.

[scordio]

Thanks for looking into this, @debanjanc01!

I see the problem, let me think about it and I'll get back to you.

[debanjanc01]

Hey @scordio , wanted to check if you've had the time to look into this.

[scordio]

Hi @debanjanc01, thanks for the ping and apologies for the terribly late feedback 😅

Hey @scordio is there an existing test case that tests this out as you have mentioned in the example for should_accept_interpolated_expressions? Or shall I add the test case to Assertions_assertThat_with_Groovy_strings_Test.groovy?

There is no existing test case at the moment and Assertions_assertThat_with_Groovy_strings_Test.groovy is definitely the right place for a new one.

Hey @scordio, the problem with groovy.lang.GString is the way it implements the equals(Object) method. It expects that the other object is also an instance of groovy.lang.GString.

After checking the topic again and looking at the Groovy sources, the test case I mentioned was definitely wrong. Instead, we should probably target something like the following:

  @Test
  void should_accept_interpolated_expressions() {
    // GIVEN
    def foo = "foo"
    def actual = /.*${foo}.*/
    // WHEN/THEN
    assertThatCharSequence(actual).isEqualTo(/.*${foo}.*/)
  }

I would still delegate to assertThat(CharSequence). As GString::equals would return false with a String input, I don't see anything wrong if isEqualTo would fail.

Would you still have time to pursue this topic? Otherwise, I'm happy to take it over.

[debanjanc01]

Hey @scordio thanks for taking the time out to revisit this. Let me check this and get back.