Java Code Examples for org.mockito.internal.verification.VerificationModeFactory#times()

The following examples show how to use org.mockito.internal.verification.VerificationModeFactory#times() . You can vote up the ones you like or vote down the ones you don't like, and go to the original project or source file by following the links above each example. You may check out the related API usage on the sidebar.
Example 1
Source File: TimesTest.java    From astor with GNU General Public License v2.0 5 votes vote down vote up
@Test
public void shouldNotAllowNegativeNumberOfInvocations() throws Exception {
    try {
        VerificationModeFactory.times(-50);
        fail();
    } catch (MockitoException e) {
        assertEquals("Negative value is not allowed here", e.getMessage());
    }
}
 
Example 2
Source File: TimesTest.java    From astor with GNU General Public License v2.0 5 votes vote down vote up
@Test
public void shouldNotAllowNegativeNumberOfInvocations() throws Exception {
    try {
        VerificationModeFactory.times(-50);
        fail();
    } catch (MockitoException e) {
        assertEquals("Negative value is not allowed here", e.getMessage());
    }
}
 
Example 3
Source File: Timeout.java    From astor with GNU General Public License v2.0 4 votes vote down vote up
public VerificationMode never() {
    return new Timeout(impl.getTreshhold(), impl.getTimeout(), VerificationModeFactory.times(0));
}
 
Example 4
Source File: Timeout.java    From astor with GNU General Public License v2.0 4 votes vote down vote up
public VerificationMode times(int wantedNumberOfInvocations) {
    return new Timeout(impl.getTreshhold(), impl.getTimeout(), VerificationModeFactory.times(wantedNumberOfInvocations));
}
 
Example 5
Source File: VerificationModeBuilder.java    From astor with GNU General Public License v2.0 4 votes vote down vote up
public Times inOrder() {
    return VerificationModeFactory.times(times);
}
 
Example 6
Source File: VerificationModeBuilder.java    From astor with GNU General Public License v2.0 4 votes vote down vote up
public Times inOrder() {
    return VerificationModeFactory.times(times);
}
 
Example 7
Source File: MockingProgressImplTest.java    From astor with GNU General Public License v2.0 3 votes vote down vote up
@Test
public void shouldStartVerificationAndPullVerificationMode() throws Exception {
    assertNull(mockingProgress.pullVerificationMode());
    
    VerificationMode mode = VerificationModeFactory.times(19);
    
    mockingProgress.verificationStarted(mode);
    
    assertSame(mode, mockingProgress.pullVerificationMode());
    
    assertNull(mockingProgress.pullVerificationMode());
}
 
Example 8
Source File: MockingProgressImplTest.java    From astor with GNU General Public License v2.0 3 votes vote down vote up
@Test
public void shouldStartVerificationAndPullVerificationMode() throws Exception {
    assertNull(mockingProgress.pullVerificationMode());
    
    VerificationMode mode = VerificationModeFactory.times(19);
    
    mockingProgress.verificationStarted(mode);
    
    assertSame(mode, mockingProgress.pullVerificationMode());
    
    assertNull(mockingProgress.pullVerificationMode());
}
 
Example 9
Source File: Mockito.java    From astor with GNU General Public License v2.0 2 votes vote down vote up
/**
 * Allows verifying exact number of invocations. E.g:
 * <pre>
 *   verify(mock, times(2)).someMethod("some arg");
 * </pre>
 * 
 * See examples in javadoc for {@link Mockito} class
 * 
 * @param wantedNumberOfInvocations wanted number of invocations 
 * 
 * @return verification mode
 */
public static VerificationMode times(int wantedNumberOfInvocations) {
    return VerificationModeFactory.times(wantedNumberOfInvocations);
}
 
Example 10
Source File: Mockito.java    From astor with GNU General Public License v2.0 2 votes vote down vote up
/**
 * Allows verifying with timeout. May be useful for testing in concurrent conditions.
 * <p>
 * It feels this feature should be used rarely - figure out a better way of testing your multi-threaded system
 * <p>
 * Not yet implemented to work with InOrder verification.
 * <pre>
 *   //passes when someMethod() is called within given time span 
 *   verify(mock, timeout(100)).someMethod();
 *   //above is an alias to:
 *   verify(mock, timeout(100).times(1)).someMethod();
 *   
 *   //passes when someMethod() is called *exactly* 2 times within given time span
 *   verify(mock, timeout(100).times(2)).someMethod();
 *
 *   //passes when someMethod() is called *at lest* 2 times within given time span
 *   verify(mock, timeout(100).atLeast(2)).someMethod();
 *   
 *   //verifies someMethod() within given time span using given verification mode
 *   //useful only if you have your own custom verification modes.
 *   verify(mock, new Timeout(100, yourOwnVerificationMode)).someMethod();
 * </pre>
 * 
 * See examples in javadoc for {@link Mockito} class
 * 
 * @param millis - time span in millis
 * 
 * @return verification mode
 */
public static VerificationWithTimeout timeout(int millis) {
    return new Timeout(millis, VerificationModeFactory.times(1));
}
 
Example 11
Source File: Mockito.java    From astor with GNU General Public License v2.0 2 votes vote down vote up
/**
 * Allows verifying exact number of invocations. E.g:
 * <pre class="code"><code class="java">
 *   verify(mock, times(2)).someMethod("some arg");
 * </code></pre>
 * 
 * See examples in javadoc for {@link Mockito} class
 * 
 * @param wantedNumberOfInvocations wanted number of invocations 
 * 
 * @return verification mode
 */
public static VerificationMode times(int wantedNumberOfInvocations) {
    return VerificationModeFactory.times(wantedNumberOfInvocations);
}
 
Example 12
Source File: Mockito.java    From astor with GNU General Public License v2.0 2 votes vote down vote up
/**
 * Allows verifying with timeout. It causes a verify to wait for a specified period of time for a desired
 * interaction rather than fails immediately if has not already happened. May be useful for testing in concurrent
 * conditions.
 * <p>
 * This differs from {@link Mockito#after after()} in that after() will wait the full period, unless
 * the final test result is known early (e.g. if a never() fails), whereas timeout() will stop early as soon
 * as verification passes, producing different behaviour when used with times(2), for example, which can pass 
 * and then later fail. In that case, timeout would pass as soon as times(2) passes, whereas after would run until
 * times(2) failed, and then fail.
 * <p>
 * It feels this feature should be used rarely - figure out a better way of testing your multi-threaded system
 * <p>
 * Not yet implemented to work with InOrder verification.
 * <pre class="code"><code class="java">
 *   //passes when someMethod() is called within given time span 
 *   verify(mock, timeout(100)).someMethod();
 *   //above is an alias to:
 *   verify(mock, timeout(100).times(1)).someMethod();
 *   
 *   //passes as soon as someMethod() has been called 2 times before the given timeout
 *   verify(mock, timeout(100).times(2)).someMethod();
 *
 *   //equivalent: this also passes as soon as someMethod() has been called 2 times before the given timeout
 *   verify(mock, timeout(100).atLeast(2)).someMethod();
 *   
 *   //verifies someMethod() within given time span using given verification mode
 *   //useful only if you have your own custom verification modes.
 *   verify(mock, new Timeout(100, yourOwnVerificationMode)).someMethod();
 * </code></pre>
 * 
 * See examples in javadoc for {@link Mockito} class
 * 
 * @param millis - time span in milliseconds
 * 
 * @return verification mode
 */
public static VerificationWithTimeout timeout(int millis) {
    return new Timeout(millis, VerificationModeFactory.times(1));
}
 
Example 13
Source File: Mockito.java    From astor with GNU General Public License v2.0 2 votes vote down vote up
/**
 * Allows verifying over a given period. It causes a verify to wait for a specified period of time for a desired
 * interaction rather than failing immediately if has not already happened. May be useful for testing in concurrent
 * conditions.
 * <p>
 * This differs from {@link Mockito#timeout timeout()} in that after() will wait the full period, whereas timeout() 
 * will stop early as soon as verification passes, producing different behaviour when used with times(2), for example,
 * which can pass and then later fail. In that case, timeout would pass as soon as times(2) passes, whereas after would
 * run the full time, which point it will fail, as times(2) has failed.
 * <p>
 * It feels this feature should be used rarely - figure out a better way of testing your multi-threaded system
 * <p>
 * Not yet implemented to work with InOrder verification.
 * <pre class="code"><code class="java">
 *   //passes after 100ms, if someMethod() has only been called once at that time. 
 *   verify(mock, after(100)).someMethod();
 *   //above is an alias to:
 *   verify(mock, after(100).times(1)).someMethod();
 *   
 *   //passes if someMethod() is called <b>*exactly*</b> 2 times after the given timespan
 *   verify(mock, after(100).times(2)).someMethod();
 *
 *   //passes if someMethod() has not been called after the given timespan
 *   verify(mock, after(100).never()).someMethod();
 *   
 *   //verifies someMethod() after a given time span using given verification mode
 *   //useful only if you have your own custom verification modes.
 *   verify(mock, new After(100, yourOwnVerificationMode)).someMethod();
 * </code></pre>
 * 
 * See examples in javadoc for {@link Mockito} class
 * 
 * @param millis - time span in milliseconds
 * 
 * @return verification mode
 */
public static VerificationAfterDelay after(int millis) {
    return new After(millis, VerificationModeFactory.times(1));
}