return MOCKITO_CORE.ignoreStubs(mocks);
/** * Creates {@link org.mockito.InOrder} object that allows verifying mocks in order. * * <pre class="code"><code class="java"> * InOrder inOrder = inOrder(firstMock, secondMock); * * inOrder.verify(firstMock).add("was called first"); * inOrder.verify(secondMock).add("was called second"); * </code></pre> * * Verification in order is flexible - <b>you don't have to verify all interactions</b> one-by-one * but only those that you are interested in testing in order. * <p> * Also, you can create InOrder object passing only mocks that are relevant for in-order verification. * <p> * <code>InOrder</code> verification is 'greedy'. You will hardly every notice it but * if you want to find out more search for 'greedy' on the Mockito * <a href="http://code.google.com/p/mockito/w/list">wiki pages</a>. * <p> * As of Mockito 1.8.4 you can verifyNoMoreInvocations() in order-sensitive way. Read more: {@link InOrder#verifyNoMoreInteractions()} * <p> * See examples in javadoc for {@link Mockito} class * * @param mocks to be verified in order * * @return InOrder object to be used to verify in order */ public static InOrder inOrder(Object... mocks) { return MOCKITO_CORE.inOrder(mocks); }
/** * Creates a mock with some non-standard settings. * <p> * The number of configuration points for a mock grows * so we need a fluent way to introduce new configuration without adding more and more overloaded Mockito.mock() methods. * Hence {@link MockSettings}. * <pre class="code"><code class="java"> * Listener mock = mock(Listener.class, withSettings() * .name("firstListner").defaultBehavior(RETURNS_SMART_NULLS)); * ); * </code></pre> * <b>Use it carefully and occasionally</b>. What might be reason your test needs non-standard mocks? * Is the code under test so complicated that it requires non-standard mocks? * Wouldn't you prefer to refactor the code under test so it is testable in a simple way? * <p> * See also {@link Mockito#withSettings()} * <p> * See examples in javadoc for {@link Mockito} class * * @param classToMock class or interface to mock * @param mockSettings additional mock settings * @return mock object */ public static <T> T mock(Class<T> classToMock, MockSettings mockSettings) { return MOCKITO_CORE.mock(classToMock, mockSettings); }
Object returnValueFor(Class<?> clazz) { if (!mockitoCore.isTypeMockable(clazz)) { return null; } return mockitoCore.mock(clazz, new MockSettingsImpl().defaultAnswer(this)); } }
/** * Verifies certain behavior happened at least once / exact number of times / never. E.g: * <pre class="code"><code class="java"> * verify(mock, times(5)).someMethod("was called five times"); * * verify(mock, atLeast(2)).someMethod("was called at least two times"); * * //you can use flexible argument matchers, e.g: * verify(mock, atLeastOnce()).someMethod(<b>anyString()</b>); * </code></pre> * * <b>times(1) is the default</b> and can be omitted * <p> * Arguments passed are compared using <code>equals()</code> method. * Read about {@link ArgumentCaptor} or {@link ArgumentMatcher} to find out other ways of matching / asserting arguments passed. * <p> * * @param mock to be verified * @param mode times(x), atLeastOnce() or never() * * @return mock object itself */ public static <T> T verify(T mock, VerificationMode mode) { return MOCKITO_CORE.verify(mock, mode); }
/** * Verifies that no interactions happened on given mocks beyond the previously verified interactions.<br/> * This method has the same behavior as {@link #verifyNoMoreInteractions(Object...)}. * * @param mocks to be verified */ public static void verifyZeroInteractions(Object... mocks) { MOCKITO_CORE.verifyNoMoreInteractions(mocks); }
@Override public <T> OngoingStubbing<T> when(T methodCall) { OngoingStubbingImpl<T> ongoingStubbing = (OngoingStubbingImpl) MOCKITO_CORE.when(methodCall); ongoingStubbing.setStrictness(Strictness.LENIENT); return ongoingStubbing; }
public void verifyNoMoreInteractions() { mockitoCore.verifyNoMoreInteractionsInOrder(mocksToBeVerifiedInOrder, this); } }
/** * Smart Mockito users hardly use this feature because they know it could be a sign of poor tests. * Normally, you don't need to reset your mocks, just create new mocks for each test method. * <p> * Instead of <code>#reset()</code> please consider writing simple, small and focused test methods over lengthy, over-specified tests. * <b>First potential code smell is <code>reset()</code> in the middle of the test method.</b> This probably means you're testing too much. * Follow the whisper of your test methods: "Please keep us small & focused on single behavior". * There are several threads about it on mockito mailing list. * <p> * The only reason we added <code>reset()</code> method is to * make it possible to work with container-injected mocks. * For more information see the FAQ (<a href="https://github.com/mockito/mockito/wiki/FAQ">here</a>). * <p> * <b>Don't harm yourself.</b> <code>reset()</code> in the middle of the test method is a code smell (you're probably testing too much). * <pre class="code"><code class="java"> * List mock = mock(List.class); * when(mock.size()).thenReturn(10); * mock.add(1); * * reset(mock); * //at this point the mock forgot any interactions & stubbing * </code></pre> * * @param <T> The Type of the mocks * @param mocks to be reset */ public static <T> void reset(T ... mocks) { MOCKITO_CORE.reset(mocks); }
MOCKITO_CORE.validateMockitoUsage();
public void verifyNoMoreInteractions(Object... mocks) { assertMocksNotEmpty(mocks); mockingProgress().validateState(); for (Object mock : mocks) { try { if (mock == null) { throw nullPassedToVerifyNoMoreInteractions(); } InvocationContainerImpl invocations = getInvocationContainer(mock); assertNotStubOnlyMock(mock); VerificationDataImpl data = new VerificationDataImpl(invocations, null); noMoreInteractions().verify(data); } catch (NotAMockException e) { throw notAMockPassedToVerifyNoMoreInteractions(); } } }
public void verifyNoMoreInteractions(Object... mocks) { assertMocksNotEmpty(mocks); mockingProgress.validateState(); for (Object mock : mocks) { try { if (mock == null) { reporter.nullPassedToVerifyNoMoreInteractions(); } InvocationContainer invocations = mockUtil.getMockHandler(mock).getInvocationContainer(); VerificationDataImpl data = new VerificationDataImpl(invocations, null); VerificationModeFactory.noMoreInteractions().verify(data); } catch (NotAMockException e) { reporter.notAMockPassedToVerifyNoMoreInteractions(); } } }
/** * Verifies certain behavior <b>happened once</b>. * <p> * Alias to <code>verify(mock, times(1))</code> E.g: * <pre class="code"><code class="java"> * verify(mock).someMethod("some arg"); * </code></pre> * Above is equivalent to: * <pre class="code"><code class="java"> * verify(mock, times(1)).someMethod("some arg"); * </code></pre> * <p> * Arguments passed are compared using <code>equals()</code> method. * Read about {@link ArgumentCaptor} or {@link ArgumentMatcher} to find out other ways of matching / asserting arguments passed. * <p> * Although it is possible to verify a stubbed invocation, usually <b>it's just redundant</b>. * Let's say you've stubbed <code>foo.bar()</code>. * If your code cares what <code>foo.bar()</code> returns then something else breaks(often before even <code>verify()</code> gets executed). * If your code doesn't care what <code>get(0)</code> returns then it should not be stubbed. * Not convinced? See <a href="http://monkeyisland.pl/2008/04/26/asking-and-telling">here</a>. * * <p> * See examples in javadoc for {@link Mockito} class * * @param mock to be verified * @return mock object itself */ public static <T> T verify(T mock) { return MOCKITO_CORE.verify(mock, times(1)); }
/** * Verifies that no interactions happened on given mocks. * <pre class="code"><code class="java"> * verifyZeroInteractions(mockOne, mockTwo); * </code></pre> * This method will also detect invocations * that occurred before the test method, for example: in <code>setUp()</code>, <code>@Before</code> method or in constructor. * Consider writing nice code that makes interactions only in test methods. * <p> * See also {@link Mockito#never()} - it is more explicit and communicates the intent well. * <p> * See examples in javadoc for {@link Mockito} class * * @param mocks to be verified */ public static void verifyZeroInteractions(Object... mocks) { MOCKITO_CORE.verifyNoMoreInteractions(mocks); }
return MOCKITO_CORE.when(methodCall);
public void verifyNoMoreInteractions() { mockitoCore.verifyNoMoreInteractionsInOrder(mocksToBeVerifiedInOrder, this); } }
/** * Smart Mockito users hardly use this feature because they know it could be a sign of poor tests. * Normally, you don't need to reset your mocks, just create new mocks for each test method. * <p> * Instead of <code>#reset()</code> please consider writing simple, small and focused test methods over lengthy, over-specified tests. * <b>First potential code smell is <code>reset()</code> in the middle of the test method.</b> This probably means you're testing too much. * Follow the whisper of your test methods: "Please keep us small & focused on single behavior". * There are several threads about it on mockito mailing list. * <p> * The only reason we added <code>reset()</code> method is to * make it possible to work with container-injected mocks. * See issue 55 (<a href="http://code.google.com/p/mockito/issues/detail?id=55">here</a>) * or FAQ (<a href="http://code.google.com/p/mockito/wiki/FAQ">here</a>). * <p> * <b>Don't harm yourself.</b> <code>reset()</code> in the middle of the test method is a code smell (you're probably testing too much). * <pre class="code"><code class="java"> * List mock = mock(List.class); * when(mock.size()).thenReturn(10); * mock.add(1); * * reset(mock); * //at this point the mock forgot any interactions & stubbing * </code></pre> * * @param <T> The Type of the mocks * @param mocks to be reset */ public static <T> void reset(T ... mocks) { MOCKITO_CORE.reset(mocks); }
MOCKITO_CORE.validateMockitoUsage();
public void verifyNoMoreInteractions(Object... mocks) { assertMocksNotEmpty(mocks); mockingProgress.validateState(); for (Object mock : mocks) { try { if (mock == null) { reporter.nullPassedToVerifyNoMoreInteractions(); } InvocationContainer invocations = mockUtil.getMockHandler(mock).getInvocationContainer(); VerificationDataImpl data = new VerificationDataImpl(invocations, null); VerificationModeFactory.noMoreInteractions().verify(data); } catch (NotAMockException e) { reporter.notAMockPassedToVerifyNoMoreInteractions(); } } }
/** * Creates a mock with some non-standard settings. * <p> * The number of configuration points for a mock grows * so we need a fluent way to introduce new configuration without adding more and more overloaded Mockito.mock() methods. * Hence {@link MockSettings}. * <pre class="code"><code class="java"> * Listener mock = mock(Listener.class, withSettings() * .name("firstListner").defaultBehavior(RETURNS_SMART_NULLS)); * ); * </code></pre> * <b>Use it carefully and occasionally</b>. What might be reason your test needs non-standard mocks? * Is the code under test so complicated that it requires non-standard mocks? * Wouldn't you prefer to refactor the code under test so it is testable in a simple way? * <p> * See also {@link Mockito#withSettings()} * <p> * See examples in javadoc for {@link Mockito} class * * @param classToMock class or interface to mock * @param mockSettings additional mock settings * @return mock object */ @CheckReturnValue public static <T> T mock(Class<T> classToMock, MockSettings mockSettings) { return MOCKITO_CORE.mock(classToMock, mockSettings); }