Distinguish foo.x and foo.getProperty("x") in call interceptor

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Distinguish foo.x and foo.getProperty("x") in call interceptor

szpak
Hi,

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?

[1] -
https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81
[2] -
https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76

Marcin

--
https://blog.solidsoft.info/ - Working code is not enough
Reply | Threaded
Open this post in threaded view
|

Re: Distinguish foo.x and foo.getProperty("x") in call interceptor

Jesper Steen Møller
On 13 Jan 2020, at 20.19, Marcin Zajączkowski <[hidden email]> wrote:
>
> Hi,
>
> 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)?
>

I wonder if this is an intended change, or a result of some refactoring? Somebody overriding getX in a subclass should see it work?

-Jesper