Eedanna / mockito

Automatically exported from code.google.com/p/mockito
0 stars 0 forks source link

verifyNoMoreInteractions does not work with Spys #314

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
    /**
     * Bug test for inorder spy
     */
    @Test
    public void testOrderIssues() {

        PrintStream testStream = spy(System.out);
        testStream.println("Hello!");
        testStream.println("Goodbye!");

        InOrder inOrder = inOrder(testStream);
        inOrder.verify(testStream).println("Hello!");
        inOrder.verify(testStream).println("Goodbye!");
        inOrder.verifyNoMoreInteractions();

    }

    /**
     * Bug test for spy
     */
    @Test
    public void testIssues() {

        PrintStream testStream = spy(System.out);
        testStream.println("Hello!");
        testStream.println("Goodbye!");

        verify(testStream).println("Hello!");
        verify(testStream).println("Goodbye!");
        verifyNoMoreInteractions(testStream);

    }

What is the expected output? What do you see instead?

I would expect 'verifyNoMoreInteractions' to pass. If fails with 'extra' found 
interactions.
It seems that calling verify on a spy adds to the invocation count.

If the spies are changed to mocks, everything works as intended.

What version of the product are you using? On what operating system?

1.9.0 on Mac OS X 10.6 with Java 6

Please provide any additional information below.

Original issue reported on code.google.com by prad...@gmail.com on 27 Jan 2012 at 9:46

GoogleCodeExporter commented 8 years ago
That's weird. I'll look int it.
Thx for the bug report

Original comment by brice.du...@gmail.com on 1 Feb 2012 at 10:20

GoogleCodeExporter commented 8 years ago
That is expected in the current architecture. E.g. the problem is that the 
implementation of PrintStream quite big and eagerly calls methods on self when 
you println. Each of those calls is recorded as an interaction and hence 
verifyNoMoreInteractions() picks them up.

I don't think it can be solved because this behaviors is required. Many times 
developers are interested on interactions on 'self' and they do verify them 
(that was the initial use case for spies that was reported via the mailing list)

One option is that we could offer a different kind of spy that would ignore 
interactions on 'self'. However it feels somewhat complicated and confusing.  
So maybe what we need instead is making sure this is very well documented?

Thanks for the report!

Original comment by szcze...@gmail.com on 1 Feb 2012 at 12:39

GoogleCodeExporter commented 8 years ago
Oh damn, invocations on self just slipped off my mind, especially on those IO 
API which are full of those self calls.

I agree that implementing is possible but complicated in the current 
architecture and potentially confusing. I would definitely favor a better 
documentation.

@pradtke You should relax your test with spies.

Original comment by brice.du...@gmail.com on 1 Feb 2012 at 1:08

GoogleCodeExporter commented 8 years ago

Original comment by brice.du...@gmail.com on 10 Feb 2012 at 8:48

GoogleCodeExporter commented 8 years ago

Original comment by brice.du...@gmail.com on 20 Jul 2012 at 10:44

GoogleCodeExporter commented 8 years ago
Yes, documentation should be improved.

Now I understand why it work this way but it was really confusing before 
reading this issue.

The way self invocations are reported also isn't really clear I think: the 
verifyNoMoreInteraction reports multiple interactions with the "external" 
invocation, without any information on the self invocation.

Original comment by apo...@gmail.com on 30 Jul 2012 at 8:48

GoogleCodeExporter commented 8 years ago
Wouldn't is be possible to let verifyNoMoreInteraction fail on spies? This 
would be fine for me. At least it would avoid some unneeded debugging until you 
find out that it does not work with spies.

Original comment by neverwri...@googlemail.com on 2 Jan 2014 at 9:26