Document AssertJ interoperability with Spock 2.4 and Groovy

[ocindev]

Describe the bug
The feature from assertj/assertj#2520 seems to be incompatible with using the StringAssertfrom assertj-core in a Groovy and Spock setup.

The then block in a spock test feature wraps any assertion code line with an groovy powerassert assert under the hood expecting the actual assertion expression to be evaluated as a boolean value. In Groovy there is the org.codehaus.groovy.runtime.DefaultGroovyMethods#asBoolean(java.lang.Object) method that Spock is calling. Due to the changes made to the AbstractStringAssert class this method is inaccessible and returns a BooleanAssert instead.

• assertj core version: 3.25.3
• java version: 17
• groovy version: 4.0.18
• test framework version: Spock 2.3-groovy-4.0
• os (if relevant):

Test case reproducing the bug

Add a test case showing the bug that we can run

import spock.lang.Specification

import static org.assertj.core.api.Assertions.assertThat

class DemoSpec extends Specification{
 def 'assert some integer'(){
 when:
 def someInteger = 10

 then:
 assertThat(someInteger).isEqualTo(10)
 }

 def 'assert some string'(){
 when:
 def someString = 'some string'

 then:
 assertThat(someString).isEqualTo('some string')
 }
}

[scordio]

If I understand correctly, AssertJ breaks Spock interoperability as soon as the then block has string assertions like in the second example but it works correctly in the first example, right?

Is there anything in the Spock documentation about this? Mainly to understand if there are additional caveats to consider.

[quaff]

I think it should be fixed at Spock side, it shouldn't wrap assert if statement.asBoolean() doesn't returns boolean.

[scordio]

I also have the feeling preventing specific method names in AssertJ shouldn't be the way to go but I'm happy to elaborate on it better.

@nweiser94 would you mind raising a related issue to Spock and see what they think? Happy to chime in, if needed.

[ocindev]

I actually think that this is not just a Spock specific issue, but a more general conflict with the Groovy language as assertj now hides Groovy built-ins.

@scordio Nonetheless, i will raise an issue to Spock to see what they think. 👍

[ocindev]

fyi: Raised Spock issue spockframework/spock#1897

[scordio]

I actually think that this is not just a Spock specific issue, but a more general conflict with the Groovy language as assertj now hides Groovy built-ins.

I'm reading about power assertions as a Groovy language feature. However, in your example, there is no assert keyword but, as you already mentioned:

The then block in a spock test feature wraps any assertion code line with an groovy powerassert assert under the hood

So it sounds like something where Spock would have control?

Looking forward to the maintainers' feedback.

[scordio]

According to spockframework/spock#1897 (comment), this isn't something to be solved in AssertJ, so I'm closing the issue but happy to reconsider in case of new arguments.

[AndreasTu]

I am really not sure here, because this also break, when Spock is not involved, but only Groovy:

import static org.assertj.core.api.Assertions.assertThat

def someString = 'some string'
assert assertThat(someString).isEqualTo('some string')

See groovy web console

AssertJ does not play well here with the Groovy semantic to use the method asBoolean() to convert it to a boolean.

@scordio Can you have a second look?

[scordio]

AssertJ does not play well here with the Groovy semantic

@AndreasTu is the Groovy semantic and the asBoolean as a reserved name documented somewhere?

The power assertions section doesn't seem to tell the full story. I would like to understand the overall impact, if it's really about asBoolean only or something more.

It seems quite an aggressive move to reserve a method name and force libraries not to use it... or, as you said in spockframework/spock#1897 (comment), maybe using AssertJ Core on top of Groovy power assertions makes little sense?

[AndreasTu]

@scordio You can find the documentation about that in the section Customizing the truth with asBoolean() methods in the Groovy documentation.

Groovy has more such methods, see operator overloading
It tries to map operators and other convertions to methods.
E.g. the + operator will map to add(), the [index] operator maps to getAt() etc.
My guess is that the general logic to that is common method names like add() in Numbers or BigDecimal BigInteger map to the + operator to make the usage more seamless.

[AndreasTu]

It seems quite an aggressive move to reserve a method name and force libraries not to use it.

I agree with that to a degree and Groovy should probably check the return type of asBoolean() better or apply the Groovy Truth recursive to the returned types, but this could also break, when there is a endless recursion with that.

But in general to map such semantics on top of some special methods in Groovy has more benefit than harm.
Because most of the time classes written only with Java in mind will work maybe 90% of the time with enhanced groovy semantics without any adaptions needed. So Groovy users get the benefit of the Java-Ecosystem with enhanced semantics.
Think of a class having a asBoolean() returning boolean or a add method , you can write stuff like that:

if(myObject){
 result += myObject
}

//instead of in Java
if(myObject.asBoolean()){
 result = result.add(myObject)
}

maybe using AssertJ Core on top of Groovy power assertions makes little sense?

My opinion would be: In general use AssertJ in Java code and use groovy power assertions in Groovy code.
The Groovy power assertions are IMHO more readable, but will only work in Groovy.

[scordio]

@AndreasTu looking at the plain Groovy example, what is the purpose of prefixing the assertThat call with assert?

We have some basic Groovy integration tests and none of them uses assert in front of the assertions.

In addition, the junit5-jupiter-starter-gradle-groovy from the JUnit samples doesn't use assert in front of assertions either.

My current impression is that there is nothing wrong with Groovy itself but only the way AssertJ is used with the Groovy language features.

I understand that Spock introduces a layer of abstraction on top of Groovy, "wiring" the content of the then block with the Groovy assert. I'm wondering if there is anything that could be done inside Spock to handle such a combination.