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
{{ message }}
Repository navigation
Spying objects not working properly since 5.3.0 #2972
starting with 5.3.0 we are unable to spy ObjectMapper with a registered JavaTimeModule.
Could this be dependent on the changes for #2877? It looks like the module has been removed after creating the spy.
With 5.2.0 everything is working fine. Please see the minimal example below.
changed the title [-]Unable to spy ObjectMapper with a registered JavaTimeModule[/-][+]Spying objects not working properly since 5.3.0[/+]on Apr 13, 2023
Which version of ByteBuddy are you using? Can you downgrade to the version of ByteBuddy that Mockito 5.2.0 used and let us know if that solves the issue?
Which version of ByteBuddy are you using? Can you downgrade to the version of ByteBuddy that Mockito 5.2.0 used and let us know if that solves the issue?
FWIW, I'm using ByteBuddy 1.14.4 (latest) with Mockito 5.2.0 without any issues, its only when I upgrade to Mockito 5.3.0 that I started having problems
We have a bunch of tests on this, so I am a bit confused. I will have a look once I find the time.
Could someone try to create a reproduction of the test without external dependencies? This would ease my work a lot, and I can use it as a regression test.
Fields of the real object that are initialized in the default constructor call are not properly set in the spy and therefore causing a different behavior at runtime. This could be solved by using MockSettings.useConstructor(), thankfully.
Another issue is more serious: also method calls are not redirected to the spy anymore - instead, the method on the mock is called. :-(
So, although the actual instance that was "spy"ied from via spiedInstance(actual).defaultAnswer(CALLS_REAL_METHODS) would yield the correct result, the method call result is the one from the additionally created mock instance.
I could solve this only by also instrumenting the methods of the spy (which should not be needed, when using "CALLS_REAL_METHODS", at least from my understanding).
Can anybody who is affected bisect the commits between Mockito 5.2.0 and 5.3.0 and let us know which commit breaks the behavior? I am still stumbled by this regression and I can't piece it together with the commits that were in this minor version release.
Activity
cmuchinsky commentedon Apr 13, 2023
Seeing similar problems with spy mocks, in my case it seems like the spy wrapper isn't calling the real methods under the covers properly
[-]Unable to spy ObjectMapper with a registered JavaTimeModule[/-][+]Spying objects not working properly since 5.3.0[/+]mmaeller commentedon Apr 13, 2023
My first thought was the issue could be the JavaTimeModule being final.
TimvdLippe commentedon Apr 13, 2023
Which version of ByteBuddy are you using? Can you downgrade to the version of ByteBuddy that Mockito 5.2.0 used and let us know if that solves the issue?
cmuchinsky commentedon Apr 13, 2023
FWIW, I'm using ByteBuddy
1.14.4(latest) with Mockito5.2.0without any issues, its only when I upgrade to Mockito5.3.0that I started having problemsmmaeller commentedon Apr 13, 2023
Hi @TimvdLippe, thanks for your response.
5.3.0 with byte-buddy 1.14.1 and 1.14.4 not working.
5.2.0 with byte-buddy 1.14.1 and 1.14.4 working.
TimvdLippe commentedon Apr 13, 2023
@raphw I think this is #2948 don't you think?
raphw commentedon Apr 13, 2023
I'd be surprised by that. Could you build Mockito but revert this one commit to see if it solves the issue?
ratoaq2 commentedon Apr 14, 2023
I'm also having intermittent issues spying instances with mockito 5.3.0
raphw commentedon Apr 14, 2023
We have a bunch of tests on this, so I am a bit confused. I will have a look once I find the time.
Could someone try to create a reproduction of the test without external dependencies? This would ease my work a lot, and I can use it as a regression test.
mmaeller commentedon Apr 14, 2023
@raphw
https://github.com/mmaeller/mockito-2972
rzanner commentedon Apr 19, 2023
We have a similar issue spying on objects.
Fields of the real object that are initialized in the default constructor call are not properly set in the spy and therefore causing a different behavior at runtime. This could be solved by using MockSettings.useConstructor(), thankfully.
Another issue is more serious: also method calls are not redirected to the spy anymore - instead, the method on the mock is called. :-(
So, although the actual instance that was "spy"ied from via spiedInstance(actual).defaultAnswer(CALLS_REAL_METHODS) would yield the correct result, the method call result is the one from the additionally created mock instance.
I could solve this only by also instrumenting the methods of the spy (which should not be needed, when using "CALLS_REAL_METHODS", at least from my understanding).
TimvdLippe commentedon Apr 20, 2023
Can anybody who is affected bisect the commits between Mockito 5.2.0 and 5.3.0 and let us know which commit breaks the behavior? I am still stumbled by this regression and I can't piece it together with the commits that were in this minor version release.
raphw commentedon Apr 21, 2023
I tried it now and it is certainly related to the change of the visibility. I am however not yet sure how this relates, looking into.
raphw commentedon Apr 21, 2023
Found out and fixed: #2983
Weakens visibility constraint for spy constructors (mockito#2983)