inOrder.verfiyNoMoreInteractions worked incorrect

[GoogleCodeExporter]

<code>
import java.util.concurrent.locks.ReadWriteLock;

import org.junit.Test;
import org.mockito.InOrder;
import org.mockito.Mockito;

public class Sample {
    @Test
    public void test() {
        ReadWriteLock readWriteLock = Mockito.mock(ReadWriteLock.class);
        InOrder order = Mockito.inOrder(readWriteLock);
        readWriteLock.readLock(); // 1
        readWriteLock.writeLock();
        // order.verify(readWriteLock).readLock(); // 2
        order.verify(readWriteLock).writeLock();
        order.verifyNoMoreInteractions(); // 3
    }
}
</code>

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

I would expect fail 'verifyNoMoreInteractions' without uncommented line 2. But 
the test was passed.

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

1.8.5, 1.9.0

Please provide any additional information below.

Original issue reported on code.google.com by erzhu...@gmail.com on 26 Feb 2012 at 9:35

[GoogleCodeExporter]

As of v1.9.0 the behavior seems to be correct. No interaction has been observed 
after the call to writeLock(), as requested by the test. The behavior is the 
one described in the Javadoc. 

"Verifies that no more interactions happened in order. Different from 
Mockito.verifyNoMoreInteractions(Object) because the order of verification 
matters."

Original comment by Jose.Pau...@gmail.com on 7 Mar 2012 at 7:25

[GoogleCodeExporter]

Approved. Mockito behaves as expected. Thx José and Eric.

Original comment by brice.du...@gmail.com on 7 Mar 2012 at 7:27

[GoogleCodeExporter]

Original comment by brice.du...@gmail.com on 8 Mar 2012 at 3:35

• Changed state: Invalid

[GoogleCodeExporter]

In this case, I would expect fail on line 
order.verify(readWriteLock).writeLock() because readWriteLock.readLock() was 
call before readWriteLock.writeLock().

Original comment by erzhu...@gmail.com on 25 Mar 2012 at 6:57

[GoogleCodeExporter]

Actually this is not intended in the verify "inOrder" semantic, it doesn't 
imply that "writeLock" in the only nor the first interaction on the mock.

Original comment by brice.du...@gmail.com on 25 Mar 2012 at 8:41