Verify with timeout does not wait for the timeout duration before failing

[GoogleCodeExporter]

import org.mockito.Mockito;

import java.util.List;

public class TestTimeout {
    @org.junit.Test
    public void testTimeout() throws Exception {
        final List mock = Mockito.mock(List.class);
        new Thread(){
            @Override
            public void run() {
                try {
                    mock.get(2);
                    Thread.sleep(1000);
                    mock.get(1);
                } catch (InterruptedException e) {
                }
            }
        }.start();
        Mockito.verify(mock, Mockito.timeout(30000)).get(1);
        Mockito.verify(mock, Mockito.timeout(30000)).get(2);
    }
}

I expect this test to pass after about one second, but it fails immediately.

Original issue reported on code.google.com by kristofer.karlsson@gmail.com on 4 Jun 2011 at 9:01

[GoogleCodeExporter]

I have faced this same issue. The scenario above can be run correctly by first 
waiting to have 2 calls: Mockito.verify(mock, 
Mockito.timeout(30000).times(2)).get(any(Integer.TYPE));

Then check for both arguments.

It seems that with timeouts is it possible to check to number of invocations, 
but not in combination with specific arguments (e.g. putting a matcher gives 
the same issue).

Original comment by wjgerrit...@cordys.com on 8 Feb 2012 at 12:52

[GoogleCodeExporter]

I'm facing the same problem with atMost(n). I'd like to check whether a certain 
condition is not met more than 1 time within 2 seconds. It seems as if it 
proceeds immediately if the atMost-condition is met (no invocations at all 
YET), instead of waiting for the timeout to expire to check if the condition is 
met.

Original comment by astellin...@cordys.com on 8 Feb 2012 at 2:01

[GoogleCodeExporter]

Makes sense, we should fix it. I think it shouldn't be difficult, i.e. we 
should wait until the timeout instead of failing early.

Original comment by szcze...@gmail.com on 11 Feb 2012 at 4:27

[GoogleCodeExporter]

+1 for this - I'm also running into problems with premature failure following 
an out of order verification, so it would be great if the next release had a fix

Original comment by brucemcp...@gmail.com on 24 Apr 2012 at 12:25

[GoogleCodeExporter]

This issue occurs if you are using JUnit.  The code in 
VerificationWithTimeoutImpl catches MockitoAssertionError, sleeps and then 
attempts to verify once more (until the timeout is reached).  Unfortunateky, if 
you have JUnit, an AssertionError is thrown instead, so the catch/sleep does 
not function.

Have fixed in the patch (attached).

Original comment by davidhar...@gmail.com on 9 Jun 2012 at 7:10

Attachments:

• VerificationWithTimeoutImpl.java

[GoogleCodeExporter]

+1 for this, I had the same problem...

Original comment by canda...@gmail.com on 12 Jul 2012 at 10:23

[GoogleCodeExporter]

It doesn't seem to be fixed in 1.9.5 RC1. Couldn't it be fixed in 1.9.5 given 
that solution is known and simple?

Original comment by marcin.k...@gmail.com on 8 Aug 2012 at 4:18

[GoogleCodeExporter]

Whenever Mockito.timeout(to).never(), Mockito.timeout(to).once(), 
Mockito.timeout(to).times(to) are used, Mockito should wait until timeout, 
otherwise the verification is not accurate. At the moment, to make these 
verifications accurate, one needs to sleep for to milliseconds then proceed 
with verifications.

Whenever Mockito.timeout(to).atLeast(...) or Mockito.atLeastOnce() are used, 
Mockito should wait up to to milliseconds, but if verification is satisfied 
sooner, it can continue.

Original comment by alex.t...@gmail.com on 21 Aug 2012 at 11:27

[GoogleCodeExporter]

I'll take a look and maybe fix that in 1.9.5.

@Alex, I need to think about it a little bit. We do want the Mockito's 
timeout() feature to work differently than just waiting the whole duration. 
Otherwise I don't see a point in this feature - one can simply do 
Thread.sleep() and then verify.

Original comment by szcze...@gmail.com on 20 Sep 2012 at 6:37

[GoogleCodeExporter]

No, not at all.

The point of the timeout features is that you can return quickly when you know 
you're guaranteed to succeed (such as for an atleast-verification).
For an atmost-verification you can fail quickly when you know you're guaranteed 
to fail.

Original comment by kristofer.karlsson@gmail.com on 20 Sep 2012 at 10:06

[GoogleCodeExporter]

Related ticket: http://code.google.com/p/mockito/issues/detail?id=347.

Original comment by syva...@yahoo.com on 20 Sep 2012 at 10:51

[GoogleCodeExporter]

I'd like to report a similar issue for:  verify(xxx, timeout(10000).times(n))

Since "times" is supposed to verify an exact number of invocations, Mockito 
should never return early.  However my unit test completes much faster than 10 
seconds, so I know Mockito is returning pretty much immediately.

Original comment by jim.news...@gmail.com on 11 Feb 2014 at 12:54

[GoogleCodeExporter]

+1, i really like this to be fixed, makes my test code kind of ugly without it
i will take a look at it myself soon

Original comment by leozi...@gmail.com on 29 Sep 2014 at 12:01

[GoogleCodeExporter]

Hey, this is already implemented in Mockito 1.10.*. Enjoy!

Original comment by szcze...@gmail.com on 29 Sep 2014 at 1:03

• Changed state: Fixed
• Added labels: Milestone-Release1.10.0

[GoogleCodeExporter]

Oh, you need to use different method than 'timeout', use 'after' instead.

Original comment by szcze...@gmail.com on 29 Sep 2014 at 1:05