You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an issue to track an ability to better handle calling go.x when the generic Java mock implementation is used for an Groovy object in Groovy 3. Currently a working (but ugly and fragile) workaround (aka "hack") is applied, but we hope to have some better way. Related discussion on the Groovy devel mailing list.
A quotation from the original message:
TL;TR. How would be best to distinguish in Groovy 3 foo.x and foo.getProperty("x") in a call (at the level of an interceptor for a mocking system)?
More detailed version.
Working on the Spock adjustment to Groovy 3, I spotted that Groovy 3 started for a property access go.x (go - some GroovyObject instance with a field "x") to call go.getProperty("x") instead of go.getX() directly (as it took place in Groovy 2). This broke tests for mocking with a property call (getX() is stubbed, but go.x is called) and forced me to detect getProperty("x") calls in a mock interceptor - to analyze deeper and check which method (here getter) is being called and if has been stubbed.
However, in addition, it should be possible to just stub direct go.getProperty("x") calls [1]. To do that, currently, I have to analyze a stack trace to detect groovy.lang.GroovyObject$getProperty.call() at
the position -3 [2] (for direct go.getProperty("x") calls) and deeper process only the other calls (go.x). It seems to work, but it's quite ugly and fragile. I wonder, how to reliably differentiate those two types of calls?
The text was updated successfully, but these errors were encountered:
This problem gets worse with Groovy >=4.0.7, because it uses now indy as default, which makes the current used hack in BaseMockInterceptor checking the caller stack useless due to MethodHandle/Indy frames. #1752 adds a test case for the behavior of >=4.0.7.
This is an issue to track an ability to better handle calling
go.x
when the generic Java mock implementation is used for an Groovy object in Groovy 3. Currently a working (but ugly and fragile) workaround (aka "hack") is applied, but we hope to have some better way. Related discussion on the Groovy devel mailing list.A quotation from the original message:
The text was updated successfully, but these errors were encountered: