Lines Matching refs:mocks
22 * Mockito library enables mocks creation, verification and stubbing.
39 * <a href="#9">9. Shorthand for mocks creation - <code>@Mock</code> annotation </a><br/>
46 * <a href="#16">16. Real partial mocks (Since 1.8.0) </a><br/>
47 * <a href="#17">17. Resetting mocks (Since 1.8.0) </a><br/>
50 * <a href="#20">20. Serializable mocks (Since 1.8.1) </a><br/>
271 * // B. Multiple mocks that must be used in a particular order
275 * //using mocks
279 * //create inOrder object passing any mocks that need to be verified in order
293 * Also, you can create InOrder object passing only mocks that are relevant for
302 * //using mocks - only mockOne is interacted
311 * //verify that other mocks were not interacted
322 * //using mocks
347 * <h3 id="9">9. <a class="meaningful_link" href="#mock_annotation">Shorthand for mocks creation - <code>@Mock</code> annotation</a></h3>
495 * <b>Before the release 1.8</b>, Mockito spies were not real partial mocks.
497 * At some point we found legitimate use cases for partial mocks
595 * Both techniques can be used for making sure certain arguments where passed to mocks.
606 * <h3 id="16">16. <a class="meaningful_link" href="#partial_mocks">Real partial mocks</a> (Since 1.8.0)</h3>
609 * Previously we considered partial mocks as code smells. However, we found a legitimate use case for partial mocks - more reading:
612 * <b>Before release 1.8</b> <code>spy()</code> was not producing real partial mocks and it was confusing for some users.
619 * //you can enable partial mock capabilities selectively on mocks:
632 * However, there are rare cases when partial mocks come handy:
634 * However, I wouldn't use partial mocks for new, test-driven & well-designed code.
639 * <h3 id="17">17. <a class="meaningful_link" href="#resetting_mocks">Resetting mocks</a> (Since 1.8.0)</h3>
642 * Normally, you don't need to reset your mocks, just create new mocks for each test method.
650 * make it possible to work with container-injected mocks.
715 * <h3 id="20">20. <a class="meaningful_link" href="#serializable_mocks">Serializable mocks</a> (Since 1.8.1)</h3>
762 * that Mockito will inject mocks in a partial mock under testing. As a remainder, please read point 16 about partial mocks.
829 * Mockito will now allow you to create mocks when stubbing.
889 * <p>Useful for spies or partial mocks of objects <strong>that are difficult to mock or spy</strong> using the usual spy API.
985 * then it tries to return mocks. If the return type cannot be mocked (e.g. is final) then plain null is returned.
1017 * Please note that this answer will return existing mocks that matches the stub. This
1092 * However, there are rare cases when partial mocks come handy:
1094 * However, I wouldn't use partial mocks for new, test-driven & well-designed code.
1124 * Specifies mock name. Naming mocks can be helpful for debugging - the name is used in all verification errors.
1126 * Beware that naming mocks is not a solution for complex code which uses too many mocks or collaborators.
1127 * <b>If you have too many mocks then refactor the code</b> so that it's easy to test/debug without necessity of naming mocks.
1129 * <b>If you use <code>@Mock</code> annotation then you've got naming mocks for free!</b> <code>@Mock</code> uses field name as mock name. {@link Mock Read more.}
1230 * <b>Use it carefully and occasionally</b>. What might be reason your test needs non-standard mocks?
1231 * Is the code under test so complicated that it requires non-standard mocks?
1257 * However, there are rare cases when partial mocks come handy:
1259 * However, I wouldn't use partial mocks for new, test-driven & well-designed code.
1505 * Normally, you don't need to reset your mocks, just create new mocks for each test method.
1513 * make it possible to work with container-injected mocks.
1527 * @param <T> The Type of the mocks
1528 * @param mocks to be reset
1530 public static <T> void reset(T ... mocks) {
1531 MOCKITO_CORE.reset(mocks);
1535 * Checks if any of given mocks has any unverified interaction.
1537 * You can use this method after you verified your mocks - to make sure that nothing
1538 * else was invoked on your mocks.
1573 * @param mocks to be verified
1575 public static void verifyNoMoreInteractions(Object... mocks) {
1576 MOCKITO_CORE.verifyNoMoreInteractions(mocks);
1580 * Verifies that no interactions happened on given mocks.
1592 * @param mocks to be verified
1594 public static void verifyZeroInteractions(Object... mocks) {
1595 MOCKITO_CORE.verifyNoMoreInteractions(mocks);
1683 * However, there are rare cases when partial mocks come handy:
1685 * However, I wouldn't use partial mocks for new, test-driven & well-designed code.
1687 * See also javadoc {@link Mockito#spy(Object)} to find out more about partial mocks.
1688 * <b>Mockito.spy() is a recommended way of creating partial mocks.</b>
1736 * Use <code>doNothing()</code> for setting void methods to do nothing. <b>Beware that void methods on mocks do nothing by default!</b>
1828 * Creates {@link org.mockito.InOrder} object that allows verifying mocks in order.
1840 * Also, you can create InOrder object passing only mocks that are relevant for in-order verification.
1850 * @param mocks to be verified in order
1854 public static InOrder inOrder(Object... mocks) {
1855 return MOCKITO_CORE.inOrder(mocks);
1859 * Ignores stubbed methods of given mocks for the sake of verification.
1866 * Other words: all <b>*stubbed*</b> methods of given mocks are marked <b>*verified*</b> so that they don't get in a way during verifyNoMoreInteractions().
1868 * This method <b>changes the input mocks</b>! This method returns input mocks just for convenience.
1878 * //stubbing mocks:
1882 * //using mocks by calling stubbed get(0) methods:
1886 * //using mocks by calling clear() methods:
1900 * //Remember that ignoreStubs() <b>*changes*</b> the input mocks and returns them for convenience.
1918 * @param mocks input mocks that will be changed
1919 * @return the same mocks that were passed in as parameters
1921 public static Object[] ignoreStubs(Object... mocks) {
1922 return MOCKITO_CORE.ignoreStubs(mocks);
2134 * Consider writing simple tests that use simple mocks.