Skip to content

Spying objects not working properly since 5.3.0 #2972

Closed

Description

@mmaeller

Hi.

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.

import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.Mockito.spy;

import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.datatype.jsr310.JavaTimeModule;
import java.time.LocalDateTime;
import java.util.concurrent.atomic.AtomicReference;
import org.junit.jupiter.api.Test;

public class ObjectMapperTest {

  @Test
  void spyObjectMapperWithJavaTimeModule() {
    var objectMapper = spy(new ObjectMapper().registerModule(new JavaTimeModule()));
    var reference = new AtomicReference<Dummy>();
    assertDoesNotThrow(
        () ->
            reference.set(
                objectMapper.readValue(
                    """
          {
          "timestamp": "2023-04-13T09:00:00"
          }
          """,
                    Dummy.class)));
    assertEquals(LocalDateTime.of(2023, 4, 13, 9, 0), reference.get().timestamp());
  }

  record Dummy(LocalDateTime timestamp) {}
}

Activity

  1. cmuchinsky commented on Apr 13, 2023

    @cmuchinsky

    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

  2. changed the title [-]Unable to spy ObjectMapper with a registered JavaTimeModule[/-] [+]Spying objects not working properly since 5.3.0[/+] on Apr 13, 2023
  3. mmaeller commented on Apr 13, 2023

    @mmaeller
    Author

    My first thought was the issue could be the JavaTimeModule being final.

  4. TimvdLippe commented on Apr 13, 2023

    @TimvdLippe
    Contributor

    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?

  5. cmuchinsky commented on Apr 13, 2023

    @cmuchinsky

    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

  6. mmaeller commented on Apr 13, 2023

    @mmaeller
    Author

    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.

  7. TimvdLippe commented on Apr 13, 2023

    @TimvdLippe
    Contributor

    @raphw I think this is #2948 don't you think?

  8. raphw commented on Apr 13, 2023

    @raphw
    Member

    I'd be surprised by that. Could you build Mockito but revert this one commit to see if it solves the issue?

  9. ratoaq2 commented on Apr 14, 2023

    @ratoaq2

    I'm also having intermittent issues spying instances with mockito 5.3.0

  10. raphw commented on Apr 14, 2023

    @raphw
    Member

    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.

  11. mmaeller commented on Apr 14, 2023

    @mmaeller
    Author
  12. rzanner commented on Apr 19, 2023

    @rzanner

    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).

  13. TimvdLippe commented on Apr 20, 2023

    @TimvdLippe
    Contributor

    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.

  14. raphw commented on Apr 21, 2023

    @raphw
    Member

    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.

  15. raphw commented on Apr 21, 2023

    @raphw
    Member

    Found out and fixed: #2983

  16. added a commit that references this issue on Sep 29, 2024
    baf59c4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions