Comments (15)
The only additional thing I could see, is to open a ticket at Groovy and ask them
I was halfway through it when I realized that it's the usage pattern in the plain example that is not OK. It's like saying that AssertJ doesn't work properly when used inside JUnit or Truth assertions... just don't do it 🙂
But as I already said in the Spockt ticket, Spock
2.4-M2
introduced the!!
prefix to disable the autoassert
for a single line.
Yes, sorry – what you already wrote went through this time 😅
In light of that, the guideline should be:
- Spock users on version < 2.4 should stay with AssertJ 2.24.2
- Spock users on version >= 2.4 can upgrade to a newer AssertJ version and use
!!
when they encounter problems
What we can do is enhance the AssertJ docs to highlight this pitfall with Spock and Groovy.
from assertj.
fyi: Raised Spock issue spockframework/spock#1897
from assertj.
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')
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?
from assertj.
assert assertThat(someString).isEqualTo('some string')
It happens to work before assertj add asBoolean
method, now the ClassCastException
is helpful to find out such weird code which should be fixed.
from assertj.
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.
from assertj.
I think it should be fixed at Spock side, it shouldn't wrap assert
if statement.asBoolean()
doesn't returns boolean.
from assertj.
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.
from assertj.
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. 👍
from assertj.
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.
from assertj.
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.
from assertj.
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?
from assertj.
@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.
from assertj.
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.
from assertj.
@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.
from assertj.
looking at the plain Groovy example, what is the purpose of prefixing the assertThat call with assert?
None. It was just a sample without Spock, where AsssertJ is "violating" the Groovy-Truth evaluation.
But I think this does not necessary need to be fixed in AssertJ, because why should a user write assert assertThat(...).isEqualTo()
or if(assertThat(...).isEqualTo())
.
I understand that Spock introduces a layer of abstraction on top of Groovy, "wiring" the content of the then block with the Groovy assert
Yes, and therefore there is an invisible assert
before the assertThat(...).isEqualTo(...)
, which is unfortunate in this case.
But as I already said in the Spockt ticket, Spock 2.4-M2
introduced the !!
prefix to disable the auto assert
for a single line.
So when AssertJ is used with Spock (2.4-M2
or later) the user could write:
//Spock code
then:
!! assertThat(someString).isEqualTo('some string')
would prevent the exception.
The only additional thing I could see, is to open a ticket at Groovy and ask them, if they would handle the case where an asBoolean()
method not returning a boolean
could be handled more gracefully, like evaluating that again with the Groovy-Truth or something.
But this could have more unwanted effects, e.g. you would have a method asBoolean():List
, then if the List
is empy the value would be false
and otherwise true
, or an endless-recursion. But this would be a discussion with the Groovy guys.
Or maybe just live with the fact, that usage of AssertJ and Groovy-Truth may throw a ClassCaseException
in certain cases.
from assertj.
Related Issues (20)
- Recursive comparison depends on the sequence of objects. HOT 4
- assertThat(collection).doesNotHaveDuplicates() is not sorted, even if the collection is HOT 12
- Recursive comparison checks for existence of fields in types that parameterize nested unordered iterables HOT 1
- `satisfiesExactlyInAnyOrder` fails if `actual` overrides `equals` HOT 4
- `isNotEqualTo(boolean)` fails if `actual` is null HOT 2
- Suggesting "hasOnlyDuplicates()" assertion HOT 3
- Field existence check for the elements of a collection field HOT 1
- Checking compared fields existence: handle containers
- ...usingRecursiveComparison().ignoringTransientFields()... HOT 7
- Unable to compare some timestamp types HOT 2
- Add AbstractAssert#matchesWith HOT 1
- AssertFactory with the ability to convert the value upfront HOT 24
- Add default recursive comparison configuration for non accessible classes and fields HOT 6
- `extracting(Function...)` propagates `Object` instead of the common base type of all extractors HOT 6
- NPE with `extracting(Function... extractors)` HOT 3
- AssertJ: issue with Assertions.assertThat().usingRecursiveComparison().isEqualTo() HOT 6
- Provide reason and possible replacement for @Deprecated HOT 3
- isEqualTo on date can lead to unexpected failures when switching time zones HOT 1
- `InstanceOfAssertFactories.array` and `InstanceOfAssertFactories.array2D` expect array type parameter instead of the one for their elements HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from assertj.