mirror of
https://github.com/apache/cloudstack.git
synced 2025-12-18 19:44:21 +01:00
2470 lines
111 KiB
HTML
2470 lines
111 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
<!--NewPage-->
|
|
<HTML>
|
|
<HEAD>
|
|
<!-- Generated by javadoc (build 1.5.0_22) on Mon May 24 23:03:13 CEST 2010 -->
|
|
<TITLE>
|
|
Mockito (Mockito API)
|
|
</TITLE>
|
|
|
|
<META NAME="keywords" CONTENT="org.mockito.Mockito class">
|
|
|
|
<LINK REL ="stylesheet" TYPE="text/css" HREF="../../stylesheet.css" TITLE="Style">
|
|
|
|
<SCRIPT type="text/javascript">
|
|
function windowTitle()
|
|
{
|
|
parent.document.title="Mockito (Mockito API)";
|
|
}
|
|
</SCRIPT>
|
|
<NOSCRIPT>
|
|
</NOSCRIPT>
|
|
|
|
</HEAD>
|
|
|
|
<BODY BGCOLOR="white" onload="windowTitle();">
|
|
|
|
|
|
<!-- ========= START OF TOP NAVBAR ======= -->
|
|
<A NAME="navbar_top"><!-- --></A>
|
|
<A HREF="#skip-navbar_top" title="Skip navigation links"></A>
|
|
<TABLE BORDER="0" WIDTH="100%" CELLPADDING="1" CELLSPACING="0" SUMMARY="">
|
|
<TR>
|
|
<TD COLSPAN=2 BGCOLOR="#EEEEFF" CLASS="NavBarCell1">
|
|
<A NAME="navbar_top_firstrow"><!-- --></A>
|
|
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="3" SUMMARY="">
|
|
<TR ALIGN="center" VALIGN="top">
|
|
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../overview-summary.html"><FONT CLASS="NavBarFont1"><B>Overview</B></FONT></A> </TD>
|
|
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="package-summary.html"><FONT CLASS="NavBarFont1"><B>Package</B></FONT></A> </TD>
|
|
<TD BGCOLOR="#FFFFFF" CLASS="NavBarCell1Rev"> <FONT CLASS="NavBarFont1Rev"><B>Class</B></FONT> </TD>
|
|
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="class-use/Mockito.html"><FONT CLASS="NavBarFont1"><B>Use</B></FONT></A> </TD>
|
|
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="package-tree.html"><FONT CLASS="NavBarFont1"><B>Tree</B></FONT></A> </TD>
|
|
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../deprecated-list.html"><FONT CLASS="NavBarFont1"><B>Deprecated</B></FONT></A> </TD>
|
|
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../index-all.html"><FONT CLASS="NavBarFont1"><B>Index</B></FONT></A> </TD>
|
|
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../help-doc.html"><FONT CLASS="NavBarFont1"><B>Help</B></FONT></A> </TD>
|
|
</TR>
|
|
</TABLE>
|
|
</TD>
|
|
<TD ALIGN="right" VALIGN="top" ROWSPAN=3><EM>
|
|
</EM>
|
|
</TD>
|
|
</TR>
|
|
|
|
<TR>
|
|
<TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">
|
|
<A HREF="../../org/mockito/Mock.html" title="annotation in org.mockito"><B>PREV CLASS</B></A>
|
|
<A HREF="../../org/mockito/MockitoAnnotations.html" title="class in org.mockito"><B>NEXT CLASS</B></A></FONT></TD>
|
|
<TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">
|
|
<A HREF="../../index.html?org/mockito/Mockito.html" target="_top"><B>FRAMES</B></A>
|
|
<A HREF="Mockito.html" target="_top"><B>NO FRAMES</B></A>
|
|
<SCRIPT type="text/javascript">
|
|
<!--
|
|
if(window==top) {
|
|
document.writeln('<A HREF="../../allclasses-noframe.html"><B>All Classes</B></A>');
|
|
}
|
|
//-->
|
|
</SCRIPT>
|
|
<NOSCRIPT>
|
|
<A HREF="../../allclasses-noframe.html"><B>All Classes</B></A>
|
|
</NOSCRIPT>
|
|
|
|
|
|
</FONT></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">
|
|
SUMMARY: NESTED | <A HREF="#field_summary">FIELD</A> | <A HREF="#constructor_summary">CONSTR</A> | <A HREF="#method_summary">METHOD</A></FONT></TD>
|
|
<TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">
|
|
DETAIL: <A HREF="#field_detail">FIELD</A> | <A HREF="#constructor_detail">CONSTR</A> | <A HREF="#method_detail">METHOD</A></FONT></TD>
|
|
</TR>
|
|
</TABLE>
|
|
<A NAME="skip-navbar_top"></A>
|
|
<!-- ========= END OF TOP NAVBAR ========= -->
|
|
|
|
<HR>
|
|
<!-- ======== START OF CLASS DATA ======== -->
|
|
<H2>
|
|
<FONT SIZE="-1">
|
|
org.mockito</FONT>
|
|
<BR>
|
|
Class Mockito</H2>
|
|
<PRE>
|
|
java.lang.Object
|
|
<IMG SRC="../../resources/inherit.gif" ALT="extended by "><A HREF="../../org/mockito/Matchers.html" title="class in org.mockito">org.mockito.Matchers</A>
|
|
<IMG SRC="../../resources/inherit.gif" ALT="extended by "><B>org.mockito.Mockito</B>
|
|
</PRE>
|
|
<DL>
|
|
<DT><B>Direct Known Subclasses:</B> <DD><A HREF="../../org/mockito/BDDMockito.html" title="class in org.mockito">BDDMockito</A></DD>
|
|
</DL>
|
|
<HR>
|
|
<DL>
|
|
<DT><PRE>public class <B>Mockito</B><DT>extends <A HREF="../../org/mockito/Matchers.html" title="class in org.mockito">Matchers</A></DL>
|
|
</PRE>
|
|
|
|
<P>
|
|
<p align="left"><img src="logo.jpg"/></p>
|
|
Mockito library enables mocks creation, verification and stubbing.
|
|
<p>
|
|
This javadoc content is also available on the <a href="http://mockito.org">http://mockito.org</a> web page.
|
|
All documentation is kept in javadocs because it guarantees consistency between what's on the web and what's in the source code.
|
|
Also, it makes possible to access documentation straight from the IDE even if you work offline.
|
|
|
|
<h1>Contents</h1>
|
|
|
|
<b>
|
|
<a href="#1">1. Let's verify some behaviour! </a><br/>
|
|
<a href="#2">2. How about some stubbing? </a><br/>
|
|
<a href="#3">3. Argument matchers </a><br/>
|
|
<a href="#4">4. Verifying exact number of invocations / at least once / never </a><br/>
|
|
<a href="#5">5. Stubbing void methods with exceptions </a><br/>
|
|
<a href="#6">6. Verification in order </a><br/>
|
|
<a href="#7">7. Making sure interaction(s) never happened on mock </a><br/>
|
|
<a href="#8">8. Finding redundant invocations </a><br/>
|
|
<a href="#9">9. Shorthand for mocks creation - @Mock annotation </a><br/>
|
|
<a href="#10">10. Stubbing consecutive calls (iterator-style stubbing) </a><br/>
|
|
<a href="#11">11. Stubbing with callbacks </a><br/>
|
|
<a href="#12">12. doThrow()|doAnswer()|doNothing()|doReturn() family of methods mostly for stubbing voids </a><br/>
|
|
<a href="#13">13. Spying on real objects </a><br/>
|
|
<a href="#14">14. Changing default return values of unstubbed invocations (Since 1.7) </a><br/>
|
|
<a href="#15">15. Capturing arguments for further assertions (Since 1.8.0) </a><br/>
|
|
<a href="#16">16. Real partial mocks (Since 1.8.0) </a><br/>
|
|
<a href="#17">17. Resetting mocks (Since 1.8.0) </a><br/>
|
|
<a href="#18">18. Troubleshooting & validating framework usage (Since 1.8.0) </a><br/>
|
|
<a href="#19">19. Aliases for behavior driven development (Since 1.8.0) </a><br/>
|
|
<a href="#20">20. Serializable mocks (Since 1.8.1) </a><br/>
|
|
<a href="#21">21. New annotations: @Captor, @Spy, @InjectMocks (Since 1.8.3) </a><br/>
|
|
<a href="#22">22. (**New**) Verification with timeout (Since 1.8.5) </a><br/>
|
|
</b>
|
|
|
|
<p>
|
|
Following examples mock a List, because everyone knows its interface (methods
|
|
like add(), get(), clear() will be used). <br>
|
|
You probably wouldn't mock List class 'in real'.
|
|
|
|
<h3 id="1">1. Let's verify some behaviour!</h3>
|
|
|
|
<pre>
|
|
//Let's import Mockito statically so that the code looks clearer
|
|
import static org.mockito.Mockito.*;
|
|
|
|
//mock creation
|
|
List mockedList = mock(List.class);
|
|
|
|
//using mock object
|
|
mockedList.add("one");
|
|
mockedList.clear();
|
|
|
|
//verification
|
|
verify(mockedList).add("one");
|
|
verify(mockedList).clear();
|
|
</pre>
|
|
|
|
<p>
|
|
Once created, mock will remember all interactions. Then you can selectively
|
|
verify whatever interaction you are interested in.
|
|
|
|
<h3 id="2">2. How about some stubbing?</h3>
|
|
|
|
<pre>
|
|
//You can mock concrete classes, not only interfaces
|
|
LinkedList mockedList = mock(LinkedList.class);
|
|
|
|
//stubbing
|
|
when(mockedList.get(0)).thenReturn("first");
|
|
when(mockedList.get(1)).thenThrow(new RuntimeException());
|
|
|
|
//following prints "first"
|
|
System.out.println(mockedList.get(0));
|
|
|
|
//following throws runtime exception
|
|
System.out.println(mockedList.get(1));
|
|
|
|
//following prints "null" because get(999) was not stubbed
|
|
System.out.println(mockedList.get(999));
|
|
|
|
//Although it is possible to verify a stubbed invocation, usually <b>it's just redundant</b>
|
|
//If your code cares what get(0) returns then something else breaks (often before even verify() gets executed).
|
|
//If your code doesn't care what get(0) returns then it should not be stubbed. Not convinced? See <a href="http://monkeyisland.pl/2008/04/26/asking-and-telling">here</a>.
|
|
verify(mockedList).get(0);
|
|
</pre>
|
|
|
|
<ul>
|
|
<li> By default, for all methods that return value, mock returns null, an
|
|
empty collection or appropriate primitive/primitive wrapper value (e.g: 0,
|
|
false, ... for int/Integer, boolean/Boolean, ...). </li>
|
|
|
|
<li> Stubbing can be overridden: for example common stubbing can go to
|
|
fixture setup but the test methods can override it.
|
|
Please note that overridding stubbing is a potential code smell that points out too much stubbing</li>
|
|
|
|
<li> Once stubbed, the method will always return stubbed value regardless
|
|
of how many times it is called. </li>
|
|
|
|
<li> Last stubbing is more important - when you stubbed the same method with
|
|
the same arguments many times. </li>
|
|
|
|
</ul>
|
|
|
|
<h3 id="3">3. Argument matchers</h3>
|
|
|
|
Mockito verifies argument values in natural java style: by using an equals() method.
|
|
Sometimes, when extra flexibility is required then you might use argument matchers:
|
|
|
|
<pre>
|
|
//stubbing using built-in anyInt() argument matcher
|
|
when(mockedList.get(anyInt())).thenReturn("element");
|
|
|
|
//stubbing using hamcrest (let's say isValid() returns your own hamcrest matcher):
|
|
when(mockedList.contains(argThat(isValid()))).thenReturn("element");
|
|
|
|
//following prints "element"
|
|
System.out.println(mockedList.get(999));
|
|
|
|
//<b>you can also verify using an argument matcher</b>
|
|
verify(mockedList).get(anyInt());
|
|
</pre>
|
|
|
|
<p>
|
|
Argument matchers allow flexible verification or stubbing.
|
|
<A HREF="../../org/mockito/Matchers.html" title="class in org.mockito"><CODE>Click here to see</CODE></A> more built-in matchers
|
|
and examples of <b>custom argument matchers / hamcrest matchers</b>.
|
|
<p>
|
|
For information solely on <b>custom argument matchers</b> check out javadoc for <A HREF="../../org/mockito/ArgumentMatcher.html" title="class in org.mockito"><CODE>ArgumentMatcher</CODE></A> class.
|
|
<p>
|
|
Be reasonable with using complicated argument matching.
|
|
The natural matching style using equals() with occasional anyX() matchers tend to give clean & simple tests.
|
|
Sometimes it's just better to refactor the code to allow equals() matching or even implement equals() method to help out with testing.
|
|
<p>
|
|
Also, read <a href="#15">section 15</a> or javadoc for <A HREF="../../org/mockito/ArgumentCaptor.html" title="class in org.mockito"><CODE>ArgumentCaptor</CODE></A> class.
|
|
<A HREF="../../org/mockito/ArgumentCaptor.html" title="class in org.mockito"><CODE>ArgumentCaptor</CODE></A> is a special implementation of an argument matcher that captures argument values for further assertions.
|
|
<p>
|
|
<b>Warning on argument matchers:</b>
|
|
<p>
|
|
If you are using argument matchers, <b>all arguments</b> have to be provided
|
|
by matchers.
|
|
<p>
|
|
E.g: (example shows verification but the same applies to stubbing):
|
|
|
|
<pre>
|
|
verify(mock).someMethod(anyInt(), anyString(), <b>eq("third argument")</b>);
|
|
//above is correct - eq() is also an argument matcher
|
|
|
|
verify(mock).someMethod(anyInt(), anyString(), <b>"third argument"</b>);
|
|
//above is incorrect - exception will be thrown because third argument is given without an argument matcher.
|
|
</pre>
|
|
|
|
<h3 id="4">4. Verifying exact number of invocations / at least x / never</h3>
|
|
|
|
<pre>
|
|
//using mock
|
|
mockedList.add("once");
|
|
|
|
mockedList.add("twice");
|
|
mockedList.add("twice");
|
|
|
|
mockedList.add("three times");
|
|
mockedList.add("three times");
|
|
mockedList.add("three times");
|
|
|
|
//following two verifications work exactly the same - times(1) is used by default
|
|
verify(mockedList).add("once");
|
|
verify(mockedList, times(1)).add("once");
|
|
|
|
//exact number of invocations verification
|
|
verify(mockedList, times(2)).add("twice");
|
|
verify(mockedList, times(3)).add("three times");
|
|
|
|
//verification using never(). never() is an alias to times(0)
|
|
verify(mockedList, never()).add("never happened");
|
|
|
|
//verification using atLeast()/atMost()
|
|
verify(mockedList, atLeastOnce()).add("three times");
|
|
verify(mockedList, atLeast(2)).add("five times");
|
|
verify(mockedList, atMost(5)).add("three times");
|
|
|
|
</pre>
|
|
|
|
<p>
|
|
<b>times(1) is the default.</b> Therefore using times(1) explicitly can be
|
|
omitted.
|
|
|
|
<h3 id="5">5. Stubbing void methods with exceptions</h3>
|
|
|
|
<pre>
|
|
doThrow(new RuntimeException()).when(mockedList).clear();
|
|
|
|
//following throws RuntimeException:
|
|
mockedList.clear();
|
|
</pre>
|
|
|
|
Read more about doThrow|doAnswer family of methods in paragraph 12.
|
|
<p>
|
|
Initially, <A HREF="../../org/mockito/Mockito.html#stubVoid(T)"><CODE>stubVoid(Object)</CODE></A> was used for stubbing voids.
|
|
Currently stubVoid() is deprecated in favor of <A HREF="../../org/mockito/Mockito.html#doThrow(java.lang.Throwable)"><CODE>doThrow(Throwable)</CODE></A>.
|
|
This is because of improved readability and consistency with the family of <A HREF="../../org/mockito/Mockito.html#doAnswer(org.mockito.stubbing.Answer)"><CODE>doAnswer(Answer)</CODE></A> methods.
|
|
|
|
<h3 id="6">6. Verification in order</h3>
|
|
|
|
<pre>
|
|
List firstMock = mock(List.class);
|
|
List secondMock = mock(List.class);
|
|
|
|
//using mocks
|
|
firstMock.add("was called first");
|
|
secondMock.add("was called second");
|
|
|
|
//create inOrder object passing any mocks that need to be verified in order
|
|
InOrder inOrder = inOrder(firstMock, secondMock);
|
|
|
|
//following will make sure that firstMock was called before secondMock
|
|
inOrder.verify(firstMock).add("was called first");
|
|
inOrder.verify(secondMock).add("was called second");
|
|
</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.
|
|
|
|
<h3 id="7">7. Making sure interaction(s) never happened on mock</h3>
|
|
|
|
<pre>
|
|
//using mocks - only mockOne is interacted
|
|
mockOne.add("one");
|
|
|
|
//ordinary verification
|
|
verify(mockOne).add("one");
|
|
|
|
//verify that method was never called on a mock
|
|
verify(mockOne, never()).add("two");
|
|
|
|
//verify that other mocks were not interacted
|
|
verifyZeroInteractions(mockTwo, mockThree);
|
|
|
|
</pre>
|
|
|
|
<h3 id="8">8. Finding redundant invocations</h3>
|
|
|
|
<pre>
|
|
//using mocks
|
|
mockedList.add("one");
|
|
mockedList.add("two");
|
|
|
|
verify(mockedList).add("one");
|
|
|
|
//following verification will fail
|
|
verifyNoMoreInteractions(mockedList);
|
|
</pre>
|
|
|
|
A word of <b>warning</b>:
|
|
Some users who did a lot of classic, expect-run-verify mocking tend to use verifyNoMoreInteractions() very often, even in every test method.
|
|
verifyNoMoreInteractions() is not recommended to use in every test method.
|
|
verifyNoMoreInteractions() is a handy assertion from the interaction testing toolkit. Use it only when it's relevant.
|
|
Abusing it leads to overspecified, less maintainable tests. You can find further reading
|
|
<a href="http://monkeyisland.pl/2008/07/12/should-i-worry-about-the-unexpected/">here</a>.
|
|
|
|
<p>
|
|
See also <A HREF="../../org/mockito/Mockito.html#never()"><CODE>never()</CODE></A> - it is more explicit and
|
|
communicates the intent well.
|
|
<p>
|
|
|
|
<h3 id="9">9. Shorthand for mocks creation - @Mock annotation</h3>
|
|
|
|
<ul>
|
|
<li>Minimizes repetitive mock creation code.</li>
|
|
<li>Makes the test class more readable.</li>
|
|
<li>Makes the verification error easier to read because the <b>field name</b>
|
|
is used to identify the mock.</li>
|
|
</ul>
|
|
|
|
<pre>
|
|
public class ArticleManagerTest {
|
|
|
|
@Mock private ArticleCalculator calculator;
|
|
@Mock private ArticleDatabase database;
|
|
@Mock private UserProvider userProvider;
|
|
|
|
private ArticleManager manager;
|
|
</pre>
|
|
|
|
<b>Important!</b> This needs to be somewhere in the base class or a test
|
|
runner:
|
|
|
|
<pre>
|
|
MockitoAnnotations.initMocks(testClass);
|
|
</pre>
|
|
|
|
You can use built-in runner: <A HREF="../../org/mockito/runners/MockitoJUnitRunner.html" title="class in org.mockito.runners"><CODE>MockitoJUnitRunner</CODE></A>.
|
|
<p>
|
|
Read more here: <A HREF="../../org/mockito/MockitoAnnotations.html" title="class in org.mockito"><CODE>MockitoAnnotations</CODE></A>
|
|
|
|
<h3 id="10"> 10. Stubbing consecutive calls (iterator-style stubbing)</h3>
|
|
|
|
Sometimes we need to stub with different return value/exception for the same
|
|
method call. Typical use case could be mocking iterators.
|
|
Original version of Mockito did not have this feature to promote simple mocking.
|
|
For example, instead of iterators one could use <CODE>Iterable</CODE> or simply
|
|
collections. Those offer natural ways of stubbing (e.g. using real
|
|
collections). In rare scenarios stubbing consecutive calls could be useful,
|
|
though:
|
|
<p>
|
|
|
|
<pre>
|
|
when(mock.someMethod("some arg"))
|
|
.thenThrow(new RuntimeException())
|
|
.thenReturn("foo");
|
|
|
|
//First call: throws runtime exception:
|
|
mock.someMethod("some arg");
|
|
|
|
//Second call: prints "foo"
|
|
System.out.println(mock.someMethod("some arg"));
|
|
|
|
//Any consecutive call: prints "foo" as well (last stubbing wins).
|
|
System.out.println(mock.someMethod("some arg"));
|
|
</pre>
|
|
|
|
Alternative, shorter version of consecutive stubbing:
|
|
|
|
<pre>
|
|
when(mock.someMethod("some arg"))
|
|
.thenReturn("one", "two", "three");
|
|
</pre>
|
|
|
|
<h3 id="11"> 11. Stubbing with callbacks</h3>
|
|
|
|
Allows stubbing with generic <A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing"><CODE>Answer</CODE></A> interface.
|
|
<p>
|
|
Yet another controversial feature which was not included in Mockito
|
|
originally. We recommend using simple stubbing with thenReturn() or
|
|
thenThrow() only. Those two should be <b>just enough</b> to test/test-drive
|
|
any clean & simple code.
|
|
|
|
<pre>
|
|
when(mock.someMethod(anyString())).thenAnswer(new Answer() {
|
|
Object answer(InvocationOnMock invocation) {
|
|
Object[] args = invocation.getArguments();
|
|
Object mock = invocation.getMock();
|
|
return "called with arguments: " + args;
|
|
}
|
|
});
|
|
|
|
//Following prints "called with arguments: foo"
|
|
System.out.println(mock.someMethod("foo"));
|
|
</pre>
|
|
|
|
<h3 id="12"> 12. doThrow()|doAnswer()|doNothing()|doReturn() family of methods for stubbing voids (mostly)</h3>
|
|
|
|
Stubbing voids requires different approach from <A HREF="../../org/mockito/Mockito.html#when(T)"><CODE>when(Object)</CODE></A> because the compiler does not like void methods inside brackets...
|
|
<p>
|
|
<A HREF="../../org/mockito/Mockito.html#doThrow(java.lang.Throwable)"><CODE>doThrow(Throwable)</CODE></A> replaces the <A HREF="../../org/mockito/Mockito.html#stubVoid(T)"><CODE>stubVoid(Object)</CODE></A> method for stubbing voids.
|
|
The main reason is improved readability and consistency with the family of doAnswer() methods.
|
|
<p>
|
|
Use doThrow() when you want to stub a void method with an exception:
|
|
<pre>
|
|
doThrow(new RuntimeException()).when(mockedList).clear();
|
|
|
|
//following throws RuntimeException:
|
|
mockedList.clear();
|
|
</pre>
|
|
|
|
Read more about other methods:
|
|
<p>
|
|
<A HREF="../../org/mockito/Mockito.html#doThrow(java.lang.Throwable)"><CODE>doThrow(Throwable)</CODE></A>
|
|
<p>
|
|
<A HREF="../../org/mockito/Mockito.html#doAnswer(org.mockito.stubbing.Answer)"><CODE>doAnswer(Answer)</CODE></A>
|
|
<p>
|
|
<A HREF="../../org/mockito/Mockito.html#doNothing()"><CODE>doNothing()</CODE></A>
|
|
<p>
|
|
<A HREF="../../org/mockito/Mockito.html#doReturn(java.lang.Object)"><CODE>doReturn(Object)</CODE></A>
|
|
|
|
<h3 id="13"> 13. Spying on real objects</h3>
|
|
|
|
You can create spies of real objects. When you use the spy then the <b>real</b> methods are called (unless a method was stubbed).
|
|
<p>
|
|
Real spies should be used <b>carefully and occasionally</b>, for example when dealing with legacy code.
|
|
|
|
<p>
|
|
Spying on real objects can be associated with "partial mocking" concept.
|
|
<b>Before the release 1.8</b>, Mockito spies were not real partial mocks.
|
|
The reason was we thought partial mock is a code smell.
|
|
At some point we found legitimate use cases for partial mocks
|
|
(3rd party interfaces, interim refactoring of legacy code, the full article is <a href=
|
|
"http://monkeyisland.pl/2009/01/13/subclass-and-override-vs-partial-mocking-vs-refactoring"
|
|
>here</a>)
|
|
<p>
|
|
|
|
<pre>
|
|
List list = new LinkedList();
|
|
List spy = spy(list);
|
|
|
|
//optionally, you can stub out some methods:
|
|
when(spy.size()).thenReturn(100);
|
|
|
|
//using the spy calls <b>real</b> methods
|
|
spy.add("one");
|
|
spy.add("two");
|
|
|
|
//prints "one" - the first element of a list
|
|
System.out.println(spy.get(0));
|
|
|
|
//size() method was stubbed - 100 is printed
|
|
System.out.println(spy.size());
|
|
|
|
//optionally, you can verify
|
|
verify(spy).add("one");
|
|
verify(spy).add("two");
|
|
</pre>
|
|
|
|
<h4>Important gotcha on spying real objects!</h4>
|
|
|
|
1. Sometimes it's impossible to use <A HREF="../../org/mockito/Mockito.html#when(T)"><CODE>when(Object)</CODE></A> for stubbing spies. Example:
|
|
|
|
<pre>
|
|
List list = new LinkedList();
|
|
List spy = spy(list);
|
|
|
|
//Impossible: real method is called so spy.get(0) throws IndexOutOfBoundsException (the list is yet empty)
|
|
when(spy.get(0)).thenReturn("foo");
|
|
|
|
//You have to use doReturn() for stubbing
|
|
doReturn("foo").when(spy).get(0);
|
|
</pre>
|
|
|
|
2. Watch out for final methods.
|
|
Mockito doesn't mock final methods so the bottom line is: when you spy on real objects + you try to stub a final method = trouble.
|
|
What will happen is the real method will be called *on mock* but *not on the real instance* you passed to the spy() method.
|
|
Typically you may get a NullPointerException because mock instances don't have fields initiated.
|
|
|
|
<h3 id="14">14. Changing default return values of unstubbed invocations (Since 1.7) </h3>
|
|
|
|
You can create a mock with specified strategy for its return values.
|
|
It's quite advanced feature and typically you don't need it to write decent tests.
|
|
However, it can be helpful for working with <b>legacy systems</b>.
|
|
<p>
|
|
It is the default answer so it will be used <b>only when you don't</b> stub the method call.
|
|
|
|
<pre>
|
|
Foo mock = mock(Foo.class, Mockito.RETURNS_SMART_NULLS);
|
|
Foo mockTwo = mock(Foo.class, new YourOwnAnswer());
|
|
</pre>
|
|
|
|
<p>
|
|
Read more about this interesting implementation of <i>Answer</i>: <A HREF="../../org/mockito/Mockito.html#RETURNS_SMART_NULLS"><CODE>RETURNS_SMART_NULLS</CODE></A>
|
|
|
|
<h3 id="15">15. Capturing arguments for further assertions (Since 1.8.0) </h3>
|
|
|
|
Mockito verifies argument values in natural java style: by using an equals() method.
|
|
This is also the recommended way of matching arguments because it makes tests clean & simple.
|
|
In some situations though, it is helpful to assert on certain arguments after the actual verification.
|
|
For example:
|
|
<pre>
|
|
ArgumentCaptor<Person> argument = ArgumentCaptor.forClass(Person.class);
|
|
verify(mock).doSomething(argument.capture());
|
|
assertEquals("John", argument.getValue().getName());
|
|
</pre>
|
|
|
|
<b>Warning:</b> it is recommended to use ArgumentCaptor with verification <b>but not</b> with stubbing.
|
|
Using ArgumentCaptor with stubbing may decrease test readability because captor is created outside of assert (aka verify or 'then') block.
|
|
Also it may reduce defect localization because if stubbed method was not called then no argument is captured.
|
|
<p>
|
|
In a way ArgumentCaptor is related to custom argument matchers (see javadoc for <A HREF="../../org/mockito/ArgumentMatcher.html" title="class in org.mockito"><CODE>ArgumentMatcher</CODE></A> class).
|
|
Both techniques can be used for making sure certain arguments where passed to mocks.
|
|
However, ArgumentCaptor may be a better fit if:
|
|
<ul>
|
|
<li>custom argument matcher is not likely to be reused</li>
|
|
<li>you just need it to assert on argument values to complete verification</li>
|
|
</ul>
|
|
Custom argument matchers via <A HREF="../../org/mockito/ArgumentMatcher.html" title="class in org.mockito"><CODE>ArgumentMatcher</CODE></A> are usually better for stubbing.
|
|
|
|
<h3 id="16">16. Real partial mocks (Since 1.8.0) </h3>
|
|
|
|
Finally, after many internal debates & discussions on the mailing list, partial mock support was added to Mockito.
|
|
Previously we considered partial mocks as code smells. However, we found a legitimate use case for partial mocks - more reading:
|
|
<a href="http://monkeyisland.pl/2009/01/13/subclass-and-override-vs-partial-mocking-vs-refactoring">here</a>
|
|
<p>
|
|
<b>Before release 1.8</b> spy() was not producing real partial mocks and it was confusing for some users.
|
|
Read more about spying: <a href="#13">here</a> or in javadoc for <A HREF="../../org/mockito/Mockito.html#spy(T)"><CODE>spy(Object)</CODE></A> method.
|
|
<p>
|
|
<pre>
|
|
//you can create partial mock with spy() method:
|
|
List list = spy(new LinkedList());
|
|
|
|
//you can enable partial mock capabilities selectively on mocks:
|
|
Foo mock = mock(Foo.class);
|
|
//Be sure the real implementation is 'safe'.
|
|
//If real implementation throws exceptions or depends on specific state of the object then you're in trouble.
|
|
when(mock.someMethod()).thenCallRealMethod();
|
|
</pre>
|
|
|
|
As usual you are going to read <b>the partial mock warning</b>:
|
|
Object oriented programming is more less tackling complexity by dividing the complexity into separate, specific, SRPy objects.
|
|
How does partial mock fit into this paradigm? Well, it just doesn't...
|
|
Partial mock usually means that the complexity has been moved to a different method on the same object.
|
|
In most cases, this is not the way you want to design your application.
|
|
<p>
|
|
However, there are rare cases when partial mocks come handy:
|
|
dealing with code you cannot change easily (3rd party interfaces, interim refactoring of legacy code etc.)
|
|
However, I wouldn't use partial mocks for new, test-driven & well-designed code.
|
|
|
|
<h3 id="17">17. Resetting mocks (Since 1.8.0) </h3>
|
|
|
|
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 reset() please consider writing simple, small and focused test methods over lengthy, over-specified tests.
|
|
<b>First potential code smell is reset() 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 reset() 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> reset() in the middle of the test method is a code smell (you're probably testing too much).
|
|
<pre>
|
|
List mock = mock(List.class);
|
|
when(mock.size()).thenReturn(10);
|
|
mock.add(1);
|
|
|
|
reset(mock);
|
|
//at this point the mock forgot any interactions & stubbing
|
|
</pre>
|
|
|
|
<h3 id="18">18. Troubleshooting & validating framework usage (Since 1.8.0) </h3>
|
|
|
|
First of all, in case of any trouble, I encourage you to read the Mockito FAQ:
|
|
<a href="http://code.google.com/p/mockito/wiki/FAQ">http://code.google.com/p/mockito/wiki/FAQ</a>
|
|
<p>
|
|
In case of questions you may also post to mockito mailing list:
|
|
<a href="http://groups.google.com/group/mockito">http://groups.google.com/group/mockito</a>
|
|
<p>
|
|
Next, you should know that Mockito validates if you use it correctly <b>all the time</b>.
|
|
However, there's a gotcha so please read the javadoc for <A HREF="../../org/mockito/Mockito.html#validateMockitoUsage()"><CODE>validateMockitoUsage()</CODE></A>
|
|
|
|
<h3 id="19">19. Aliases for behavior driven development (Since 1.8.0) </h3>
|
|
|
|
Behavior Driven Development style of writing tests uses <b>//given //when //then</b> comments as fundamental parts of your test methods.
|
|
This is exactly how we write our tests and we warmly encourage you to do so!
|
|
<p>
|
|
Start learning about BDD here: <a href="http://en.wikipedia.org/wiki/Behavior_Driven_Development">http://en.wikipedia.org/wiki/Behavior_Driven_Development</a>
|
|
<p>
|
|
The problem is that current stubbing api with canonical role of <b>when</b> word does not integrate nicely with <b>//given //when //then</b> comments.
|
|
It's because stubbing belongs to <b>given</b> component of the test and not to the <b>when</b> component of the test.
|
|
Hence <A HREF="../../org/mockito/BDDMockito.html" title="class in org.mockito"><CODE>BDDMockito</CODE></A> class introduces an alias so that you stub method calls with <A HREF="../../org/mockito/BDDMockito.html#given(T)"><CODE>BDDMockito.given(Object)</CODE></A> method.
|
|
Now it really nicely integrates with the <b>given</b> component of a BDD style test!
|
|
<p>
|
|
Here is how the test might look like:
|
|
<pre>
|
|
import static org.mockito.BDDMockito.*;
|
|
|
|
Seller seller = mock(Seller.class);
|
|
Shop shop = new Shop(seller);
|
|
|
|
public void shouldBuyBread() throws Exception {
|
|
//given
|
|
given(seller.askForBread()).willReturn(new Bread());
|
|
|
|
//when
|
|
Goods goods = shop.buyBread();
|
|
|
|
//then
|
|
assertThat(goods, containBread());
|
|
}
|
|
</pre>
|
|
|
|
<h3 id="20">20. (**New**) Serializable mocks (Since 1.8.1) </h3>
|
|
|
|
Mocks can be made serializable. With this feature you can use a mock in a place that requires dependencies to be serializable.
|
|
<p>
|
|
WARNING: This should be rarely used in unit testing.
|
|
<p>
|
|
The behaviour was implemented for a specific use case of a BDD spec that had an unreliable external dependency. This
|
|
was in a web environment and the objects from the external dependency were being serialized to pass between layers.
|
|
<p>
|
|
To create serializable mock use <A HREF="../../org/mockito/MockSettings.html#serializable()"><CODE>MockSettings.serializable()</CODE></A>:
|
|
<pre>
|
|
List serializableMock = mock(List.class, withSettings().serializable());
|
|
</pre>
|
|
<p>
|
|
The mock can be serialized assuming all the normal <a href='http://java.sun.com/j2se/1.5.0/docs/api/java/io/Serializable.html'>
|
|
serialization requirements</a> are met by the class.
|
|
<p>
|
|
Making a real object spy serializable is a bit more effort as the spy(...) method does not have an overloaded version
|
|
which accepts MockSettings. No worries, you will hardly ever use it.
|
|
|
|
<pre>
|
|
List<Object> list = new ArrayList<Object>();
|
|
List<Object> spy = mock(ArrayList.class, withSettings()
|
|
.spiedInstance(list)
|
|
.defaultAnswer(CALLS_REAL_METHODS)
|
|
.serializable());
|
|
</pre>
|
|
|
|
<h3 id="21">21. (**New**) New annotations: @Captor, @Spy, @InjectMocks (Since 1.8.3) </h3>
|
|
<p>
|
|
Release 1.8.3 brings new annotations that may be helpful on occasion:
|
|
|
|
<ul>
|
|
<li>@<A HREF="../../org/mockito/Captor.html" title="annotation in org.mockito"><CODE>Captor</CODE></A> simplifies creation of <A HREF="../../org/mockito/ArgumentCaptor.html" title="class in org.mockito"><CODE>ArgumentCaptor</CODE></A>
|
|
- useful when the argument to capture is a nasty generic class and you want to avoid compiler warnings
|
|
<li>@<A HREF="../../org/mockito/Spy.html" title="annotation in org.mockito"><CODE>Spy</CODE></A> - you can use it instead <A HREF="../../org/mockito/Mockito.html#spy(T)"><CODE>spy(Object)</CODE></A>.
|
|
<li>@<A HREF="../../org/mockito/InjectMocks.html" title="annotation in org.mockito"><CODE>InjectMocks</CODE></A> - injects mocks into tested object automatically.
|
|
</ul>
|
|
<p>
|
|
All new annotations are *only* processed on <A HREF="../../org/mockito/MockitoAnnotations.html#initMocks(java.lang.Object)"><CODE>MockitoAnnotations.initMocks(Object)</CODE></A>
|
|
<p>
|
|
<h3 id="22">22. (**New**) Verification with timeout (Since 1.8.5) </h3>
|
|
<p>
|
|
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.
|
|
<p>
|
|
Examples:
|
|
<p>
|
|
<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>
|
|
<P>
|
|
|
|
<P>
|
|
<HR>
|
|
|
|
<P>
|
|
<!-- =========== FIELD SUMMARY =========== -->
|
|
|
|
<A NAME="field_summary"><!-- --></A>
|
|
<TABLE BORDER="1" WIDTH="100%" CELLPADDING="3" CELLSPACING="0" SUMMARY="">
|
|
<TR BGCOLOR="#CCCCFF" CLASS="TableHeadingColor">
|
|
<TH ALIGN="left" COLSPAN="2"><FONT SIZE="+2">
|
|
<B>Field Summary</B></FONT></TH>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing">Answer</A><java.lang.Object></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#CALLS_REAL_METHODS">CALLS_REAL_METHODS</A></B></CODE>
|
|
|
|
<BR>
|
|
Optional Answer to be used with <A HREF="../../org/mockito/Mockito.html#mock(java.lang.Class, org.mockito.stubbing.Answer)"><CODE>mock(Class, Answer)</CODE></A></TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing">Answer</A><java.lang.Object></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#RETURNS_DEEP_STUBS">RETURNS_DEEP_STUBS</A></B></CODE>
|
|
|
|
<BR>
|
|
Optional Answer to be used with <A HREF="../../org/mockito/Mockito.html#mock(java.lang.Class, org.mockito.stubbing.Answer)"><CODE>mock(Class, Answer)</CODE></A></TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing">Answer</A><java.lang.Object></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#RETURNS_DEFAULTS">RETURNS_DEFAULTS</A></B></CODE>
|
|
|
|
<BR>
|
|
The default Answer of every mock <b>if</b> the mock was not stubbed.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing">Answer</A><java.lang.Object></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#RETURNS_MOCKS">RETURNS_MOCKS</A></B></CODE>
|
|
|
|
<BR>
|
|
Optional Answer to be used with <A HREF="../../org/mockito/Mockito.html#mock(java.lang.Class, org.mockito.stubbing.Answer)"><CODE>mock(Class, Answer)</CODE></A></TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing">Answer</A><java.lang.Object></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#RETURNS_SMART_NULLS">RETURNS_SMART_NULLS</A></B></CODE>
|
|
|
|
<BR>
|
|
Optional Answer to be used with <A HREF="../../org/mockito/Mockito.html#mock(java.lang.Class, org.mockito.stubbing.Answer)"><CODE>mock(Class, Answer)</CODE></A></TD>
|
|
</TR>
|
|
</TABLE>
|
|
|
|
<!-- ======== CONSTRUCTOR SUMMARY ======== -->
|
|
|
|
<A NAME="constructor_summary"><!-- --></A>
|
|
<TABLE BORDER="1" WIDTH="100%" CELLPADDING="3" CELLSPACING="0" SUMMARY="">
|
|
<TR BGCOLOR="#CCCCFF" CLASS="TableHeadingColor">
|
|
<TH ALIGN="left" COLSPAN="2"><FONT SIZE="+2">
|
|
<B>Constructor Summary</B></FONT></TH>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#Mockito()">Mockito</A></B>()</CODE>
|
|
|
|
<BR>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
|
|
<!-- ========== METHOD SUMMARY =========== -->
|
|
|
|
<A NAME="method_summary"><!-- --></A>
|
|
<TABLE BORDER="1" WIDTH="100%" CELLPADDING="3" CELLSPACING="0" SUMMARY="">
|
|
<TR BGCOLOR="#CCCCFF" CLASS="TableHeadingColor">
|
|
<TH ALIGN="left" COLSPAN="2"><FONT SIZE="+2">
|
|
<B>Method Summary</B></FONT></TH>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/verification/VerificationMode.html" title="interface in org.mockito.verification">VerificationMode</A></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#atLeast(int)">atLeast</A></B>(int minNumberOfInvocations)</CODE>
|
|
|
|
<BR>
|
|
Allows at-least-x verification.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/verification/VerificationMode.html" title="interface in org.mockito.verification">VerificationMode</A></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#atLeastOnce()">atLeastOnce</A></B>()</CODE>
|
|
|
|
<BR>
|
|
Allows at-least-once verification.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/verification/VerificationMode.html" title="interface in org.mockito.verification">VerificationMode</A></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#atMost(int)">atMost</A></B>(int maxNumberOfInvocations)</CODE>
|
|
|
|
<BR>
|
|
Allows at-most-x verification.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/stubbing/Stubber.html" title="interface in org.mockito.stubbing">Stubber</A></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#doAnswer(org.mockito.stubbing.Answer)">doAnswer</A></B>(<A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing">Answer</A> answer)</CODE>
|
|
|
|
<BR>
|
|
Use doAnswer() when you want to stub a void method with generic <A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing"><CODE>Answer</CODE></A>.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/stubbing/Stubber.html" title="interface in org.mockito.stubbing">Stubber</A></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#doCallRealMethod()">doCallRealMethod</A></B>()</CODE>
|
|
|
|
<BR>
|
|
Use doCallRealMethod() when you want to call the real implementation of a method.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/stubbing/Stubber.html" title="interface in org.mockito.stubbing">Stubber</A></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#doNothing()">doNothing</A></B>()</CODE>
|
|
|
|
<BR>
|
|
Use doNothing() for setting void methods to do nothing.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/stubbing/Stubber.html" title="interface in org.mockito.stubbing">Stubber</A></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#doReturn(java.lang.Object)">doReturn</A></B>(java.lang.Object toBeReturned)</CODE>
|
|
|
|
<BR>
|
|
Use doReturn() in those rare occasions when you cannot use <A HREF="../../org/mockito/Mockito.html#when(T)"><CODE>when(Object)</CODE></A>.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/stubbing/Stubber.html" title="interface in org.mockito.stubbing">Stubber</A></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#doThrow(java.lang.Throwable)">doThrow</A></B>(java.lang.Throwable toBeThrown)</CODE>
|
|
|
|
<BR>
|
|
Use doThrow() when you want to stub the void method with an exception.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/InOrder.html" title="interface in org.mockito">InOrder</A></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#inOrder(java.lang.Object...)">inOrder</A></B>(java.lang.Object... mocks)</CODE>
|
|
|
|
<BR>
|
|
Creates InOrder object that allows verifying mocks in order.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static
|
|
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" SUMMARY="">
|
|
<TR ALIGN="right" VALIGN="">
|
|
<TD NOWRAP><FONT SIZE="-1">
|
|
<CODE><T> T</CODE></FONT></TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#mock(java.lang.Class)">mock</A></B>(java.lang.Class<T> classToMock)</CODE>
|
|
|
|
<BR>
|
|
Creates mock object of given class or interface.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static
|
|
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" SUMMARY="">
|
|
<TR ALIGN="right" VALIGN="">
|
|
<TD NOWRAP><FONT SIZE="-1">
|
|
<CODE><T> T</CODE></FONT></TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#mock(java.lang.Class, org.mockito.stubbing.Answer)">mock</A></B>(java.lang.Class<T> classToMock,
|
|
<A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing">Answer</A> defaultAnswer)</CODE>
|
|
|
|
<BR>
|
|
Creates mock with a specified strategy for its answers to interactions.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static
|
|
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" SUMMARY="">
|
|
<TR ALIGN="right" VALIGN="">
|
|
<TD NOWRAP><FONT SIZE="-1">
|
|
<CODE><T> T</CODE></FONT></TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#mock(java.lang.Class, org.mockito.MockSettings)">mock</A></B>(java.lang.Class<T> classToMock,
|
|
<A HREF="../../org/mockito/MockSettings.html" title="interface in org.mockito">MockSettings</A> mockSettings)</CODE>
|
|
|
|
<BR>
|
|
Creates a mock with some non-standard settings.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static
|
|
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" SUMMARY="">
|
|
<TR ALIGN="right" VALIGN="">
|
|
<TD NOWRAP><FONT SIZE="-1">
|
|
<CODE><T> T</CODE></FONT></TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#mock(java.lang.Class, org.mockito.ReturnValues)">mock</A></B>(java.lang.Class<T> classToMock,
|
|
<A HREF="../../org/mockito/ReturnValues.html" title="interface in org.mockito">ReturnValues</A> returnValues)</CODE>
|
|
|
|
<BR>
|
|
<B>Deprecated.</B> <I><b>Please use mock(Foo.class, defaultAnswer);</b>
|
|
<p>
|
|
See <A HREF="../../org/mockito/Mockito.html#mock(java.lang.Class, org.mockito.stubbing.Answer)"><CODE>mock(Class, Answer)</CODE></A>
|
|
<p>
|
|
Why it is deprecated? ReturnValues is being replaced by Answer
|
|
for better consistency & interoperability of the framework.
|
|
Answer interface has been in Mockito for a while and it has the same responsibility as ReturnValues.
|
|
There's no point in mainting exactly the same interfaces.
|
|
<p>
|
|
Creates mock with a specified strategy for its return values.
|
|
It's quite advanced feature and typically you don't need it to write decent tests.
|
|
However it can be helpful when working with legacy systems.
|
|
<p>
|
|
Obviously return values are used only when you don't stub the method call.
|
|
|
|
<pre>
|
|
Foo mock = mock(Foo.class, Mockito.RETURNS_SMART_NULLS);
|
|
Foo mockTwo = mock(Foo.class, new YourOwnReturnValues());
|
|
</pre>
|
|
|
|
<p>See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class</p></I></TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static
|
|
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" SUMMARY="">
|
|
<TR ALIGN="right" VALIGN="">
|
|
<TD NOWRAP><FONT SIZE="-1">
|
|
<CODE><T> T</CODE></FONT></TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#mock(java.lang.Class, java.lang.String)">mock</A></B>(java.lang.Class<T> classToMock,
|
|
java.lang.String name)</CODE>
|
|
|
|
<BR>
|
|
Specifies mock name.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/verification/VerificationMode.html" title="interface in org.mockito.verification">VerificationMode</A></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#never()">never</A></B>()</CODE>
|
|
|
|
<BR>
|
|
Alias to times(0), see <A HREF="../../org/mockito/Mockito.html#times(int)"><CODE>times(int)</CODE></A></TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/verification/VerificationMode.html" title="interface in org.mockito.verification">VerificationMode</A></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#only()">only</A></B>()</CODE>
|
|
|
|
<BR>
|
|
Allows checking if given method was the only one invoked.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static
|
|
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" SUMMARY="">
|
|
<TR ALIGN="right" VALIGN="">
|
|
<TD NOWRAP><FONT SIZE="-1">
|
|
<CODE><T> void</CODE></FONT></TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#reset(T...)">reset</A></B>(T... mocks)</CODE>
|
|
|
|
<BR>
|
|
Smart Mockito users hardly use this feature because they know it could be a sign of poor tests.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static
|
|
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" SUMMARY="">
|
|
<TR ALIGN="right" VALIGN="">
|
|
<TD NOWRAP><FONT SIZE="-1">
|
|
<CODE><T> T</CODE></FONT></TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#spy(T)">spy</A></B>(T object)</CODE>
|
|
|
|
<BR>
|
|
Creates a spy of the real object.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static
|
|
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" SUMMARY="">
|
|
<TR ALIGN="right" VALIGN="">
|
|
<TD NOWRAP><FONT SIZE="-1">
|
|
<CODE><T> <A HREF="../../org/mockito/stubbing/DeprecatedOngoingStubbing.html" title="interface in org.mockito.stubbing">DeprecatedOngoingStubbing</A><T></CODE></FONT></TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#stub(T)">stub</A></B>(T methodCall)</CODE>
|
|
|
|
<BR>
|
|
Stubs a method call with return value or an exception.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static
|
|
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" SUMMARY="">
|
|
<TR ALIGN="right" VALIGN="">
|
|
<TD NOWRAP><FONT SIZE="-1">
|
|
<CODE><T> <A HREF="../../org/mockito/stubbing/VoidMethodStubbable.html" title="interface in org.mockito.stubbing">VoidMethodStubbable</A><T></CODE></FONT></TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#stubVoid(T)">stubVoid</A></B>(T mock)</CODE>
|
|
|
|
<BR>
|
|
<B>Deprecated.</B> <I>Use <A HREF="../../org/mockito/Mockito.html#doThrow(java.lang.Throwable)"><CODE>doThrow(Throwable)</CODE></A> method for stubbing voids</I></TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/verification/VerificationWithTimeout.html" title="interface in org.mockito.verification">VerificationWithTimeout</A></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#timeout(int)">timeout</A></B>(int millis)</CODE>
|
|
|
|
<BR>
|
|
Allows verifying with timeout.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/verification/VerificationMode.html" title="interface in org.mockito.verification">VerificationMode</A></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#times(int)">times</A></B>(int wantedNumberOfInvocations)</CODE>
|
|
|
|
<BR>
|
|
Allows verifying exact number of invocations.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static void</CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#validateMockitoUsage()">validateMockitoUsage</A></B>()</CODE>
|
|
|
|
<BR>
|
|
First of all, in case of any trouble, I encourage you to read the Mockito FAQ: <a href="http://code.google.com/p/mockito/wiki/FAQ">http://code.google.com/p/mockito/wiki/FAQ</a></TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static
|
|
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" SUMMARY="">
|
|
<TR ALIGN="right" VALIGN="">
|
|
<TD NOWRAP><FONT SIZE="-1">
|
|
<CODE><T> T</CODE></FONT></TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#verify(T)">verify</A></B>(T mock)</CODE>
|
|
|
|
<BR>
|
|
Verifies certain behavior <b>happened once</b></TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static
|
|
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" SUMMARY="">
|
|
<TR ALIGN="right" VALIGN="">
|
|
<TD NOWRAP><FONT SIZE="-1">
|
|
<CODE><T> T</CODE></FONT></TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#verify(T, org.mockito.verification.VerificationMode)">verify</A></B>(T mock,
|
|
<A HREF="../../org/mockito/verification/VerificationMode.html" title="interface in org.mockito.verification">VerificationMode</A> mode)</CODE>
|
|
|
|
<BR>
|
|
Verifies certain behavior happened at least once / exact number of times / never.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static void</CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#verifyNoMoreInteractions(java.lang.Object...)">verifyNoMoreInteractions</A></B>(java.lang.Object... mocks)</CODE>
|
|
|
|
<BR>
|
|
Checks if any of given mocks has any unverified interaction.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static void</CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#verifyZeroInteractions(java.lang.Object...)">verifyZeroInteractions</A></B>(java.lang.Object... mocks)</CODE>
|
|
|
|
<BR>
|
|
Verifies that no interactions happened on given mocks.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static
|
|
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" SUMMARY="">
|
|
<TR ALIGN="right" VALIGN="">
|
|
<TD NOWRAP><FONT SIZE="-1">
|
|
<CODE><T> <A HREF="../../org/mockito/stubbing/OngoingStubbing.html" title="interface in org.mockito.stubbing">OngoingStubbing</A><T></CODE></FONT></TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#when(T)">when</A></B>(T methodCall)</CODE>
|
|
|
|
<BR>
|
|
Enables stubbing methods.</TD>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD ALIGN="right" VALIGN="top" WIDTH="1%"><FONT SIZE="-1">
|
|
<CODE>static <A HREF="../../org/mockito/MockSettings.html" title="interface in org.mockito">MockSettings</A></CODE></FONT></TD>
|
|
<TD><CODE><B><A HREF="../../org/mockito/Mockito.html#withSettings()">withSettings</A></B>()</CODE>
|
|
|
|
<BR>
|
|
Allows mock creation with additional mock settings.</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<A NAME="methods_inherited_from_class_org.mockito.Matchers"><!-- --></A>
|
|
<TABLE BORDER="1" WIDTH="100%" CELLPADDING="3" CELLSPACING="0" SUMMARY="">
|
|
<TR BGCOLOR="#EEEEFF" CLASS="TableSubHeadingColor">
|
|
<TH ALIGN="left"><B>Methods inherited from class org.mockito.<A HREF="../../org/mockito/Matchers.html" title="class in org.mockito">Matchers</A></B></TH>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD><CODE><A HREF="../../org/mockito/Matchers.html#any()">any</A>, <A HREF="../../org/mockito/Matchers.html#any(java.lang.Class)">any</A>, <A HREF="../../org/mockito/Matchers.html#anyBoolean()">anyBoolean</A>, <A HREF="../../org/mockito/Matchers.html#anyByte()">anyByte</A>, <A HREF="../../org/mockito/Matchers.html#anyChar()">anyChar</A>, <A HREF="../../org/mockito/Matchers.html#anyCollection()">anyCollection</A>, <A HREF="../../org/mockito/Matchers.html#anyCollectionOf(java.lang.Class)">anyCollectionOf</A>, <A HREF="../../org/mockito/Matchers.html#anyDouble()">anyDouble</A>, <A HREF="../../org/mockito/Matchers.html#anyFloat()">anyFloat</A>, <A HREF="../../org/mockito/Matchers.html#anyInt()">anyInt</A>, <A HREF="../../org/mockito/Matchers.html#anyList()">anyList</A>, <A HREF="../../org/mockito/Matchers.html#anyListOf(java.lang.Class)">anyListOf</A>, <A HREF="../../org/mockito/Matchers.html#anyLong()">anyLong</A>, <A HREF="../../org/mockito/Matchers.html#anyMap()">anyMap</A>, <A HREF="../../org/mockito/Matchers.html#anyObject()">anyObject</A>, <A HREF="../../org/mockito/Matchers.html#anySet()">anySet</A>, <A HREF="../../org/mockito/Matchers.html#anySetOf(java.lang.Class)">anySetOf</A>, <A HREF="../../org/mockito/Matchers.html#anyShort()">anyShort</A>, <A HREF="../../org/mockito/Matchers.html#anyString()">anyString</A>, <A HREF="../../org/mockito/Matchers.html#anyVararg()">anyVararg</A>, <A HREF="../../org/mockito/Matchers.html#argThat(org.hamcrest.Matcher)">argThat</A>, <A HREF="../../org/mockito/Matchers.html#booleanThat(org.hamcrest.Matcher)">booleanThat</A>, <A HREF="../../org/mockito/Matchers.html#byteThat(org.hamcrest.Matcher)">byteThat</A>, <A HREF="../../org/mockito/Matchers.html#charThat(org.hamcrest.Matcher)">charThat</A>, <A HREF="../../org/mockito/Matchers.html#contains(java.lang.String)">contains</A>, <A HREF="../../org/mockito/Matchers.html#doubleThat(org.hamcrest.Matcher)">doubleThat</A>, <A HREF="../../org/mockito/Matchers.html#endsWith(java.lang.String)">endsWith</A>, <A HREF="../../org/mockito/Matchers.html#eq(boolean)">eq</A>, <A HREF="../../org/mockito/Matchers.html#eq(byte)">eq</A>, <A HREF="../../org/mockito/Matchers.html#eq(char)">eq</A>, <A HREF="../../org/mockito/Matchers.html#eq(double)">eq</A>, <A HREF="../../org/mockito/Matchers.html#eq(float)">eq</A>, <A HREF="../../org/mockito/Matchers.html#eq(int)">eq</A>, <A HREF="../../org/mockito/Matchers.html#eq(long)">eq</A>, <A HREF="../../org/mockito/Matchers.html#eq(short)">eq</A>, <A HREF="../../org/mockito/Matchers.html#eq(T)">eq</A>, <A HREF="../../org/mockito/Matchers.html#floatThat(org.hamcrest.Matcher)">floatThat</A>, <A HREF="../../org/mockito/Matchers.html#intThat(org.hamcrest.Matcher)">intThat</A>, <A HREF="../../org/mockito/Matchers.html#isA(java.lang.Class)">isA</A>, <A HREF="../../org/mockito/Matchers.html#isNotNull()">isNotNull</A>, <A HREF="../../org/mockito/Matchers.html#isNull()">isNull</A>, <A HREF="../../org/mockito/Matchers.html#longThat(org.hamcrest.Matcher)">longThat</A>, <A HREF="../../org/mockito/Matchers.html#matches(java.lang.String)">matches</A>, <A HREF="../../org/mockito/Matchers.html#notNull()">notNull</A>, <A HREF="../../org/mockito/Matchers.html#refEq(T, java.lang.String...)">refEq</A>, <A HREF="../../org/mockito/Matchers.html#same(T)">same</A>, <A HREF="../../org/mockito/Matchers.html#shortThat(org.hamcrest.Matcher)">shortThat</A>, <A HREF="../../org/mockito/Matchers.html#startsWith(java.lang.String)">startsWith</A></CODE></TD>
|
|
</TR>
|
|
</TABLE>
|
|
<A NAME="methods_inherited_from_class_java.lang.Object"><!-- --></A>
|
|
<TABLE BORDER="1" WIDTH="100%" CELLPADDING="3" CELLSPACING="0" SUMMARY="">
|
|
<TR BGCOLOR="#EEEEFF" CLASS="TableSubHeadingColor">
|
|
<TH ALIGN="left"><B>Methods inherited from class java.lang.Object</B></TH>
|
|
</TR>
|
|
<TR BGCOLOR="white" CLASS="TableRowColor">
|
|
<TD><CODE>clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait</CODE></TD>
|
|
</TR>
|
|
</TABLE>
|
|
|
|
<P>
|
|
|
|
<!-- ============ FIELD DETAIL =========== -->
|
|
|
|
<A NAME="field_detail"><!-- --></A>
|
|
<TABLE BORDER="1" WIDTH="100%" CELLPADDING="3" CELLSPACING="0" SUMMARY="">
|
|
<TR BGCOLOR="#CCCCFF" CLASS="TableHeadingColor">
|
|
<TH ALIGN="left" COLSPAN="1"><FONT SIZE="+2">
|
|
<B>Field Detail</B></FONT></TH>
|
|
</TR>
|
|
</TABLE>
|
|
|
|
<A NAME="RETURNS_DEFAULTS"><!-- --></A><H3>
|
|
RETURNS_DEFAULTS</H3>
|
|
<PRE>
|
|
public static final <A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing">Answer</A><java.lang.Object> <B>RETURNS_DEFAULTS</B></PRE>
|
|
<DL>
|
|
<DD>The default Answer of every mock <b>if</b> the mock was not stubbed.
|
|
Typically it just returns some empty value.
|
|
<p>
|
|
<A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing"><CODE>Answer</CODE></A> can be used to define the return values of unstubbed invocations.
|
|
<p>
|
|
This implementation first tries the global configuration.
|
|
If there is no global configuration then it uses <A HREF="../../org/mockito/internal/stubbing/defaultanswers/ReturnsEmptyValues.html" title="class in org.mockito.internal.stubbing.defaultanswers"><CODE>ReturnsEmptyValues</CODE></A> (returns zeros, empty collections, nulls, etc.)
|
|
<P>
|
|
<DL>
|
|
</DL>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="RETURNS_SMART_NULLS"><!-- --></A><H3>
|
|
RETURNS_SMART_NULLS</H3>
|
|
<PRE>
|
|
public static final <A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing">Answer</A><java.lang.Object> <B>RETURNS_SMART_NULLS</B></PRE>
|
|
<DL>
|
|
<DD>Optional Answer to be used with <A HREF="../../org/mockito/Mockito.html#mock(java.lang.Class, org.mockito.stubbing.Answer)"><CODE>mock(Class, Answer)</CODE></A>
|
|
<p>
|
|
<A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing"><CODE>Answer</CODE></A> can be used to define the return values of unstubbed invocations.
|
|
<p>
|
|
This implementation can be helpful when working with legacy code.
|
|
Unstubbed methods often return null. If your code uses the object returned by an unstubbed call you get a NullPointerException.
|
|
This implementation of Answer <b>returns SmartNull instead of null</b>.
|
|
SmartNull gives nicer exception message than NPE because it points out the line where unstubbed method was called. You just click on the stack trace.
|
|
<p>
|
|
ReturnsSmartNulls first tries to return ordinary return values (see <A HREF="../../org/mockito/internal/stubbing/defaultanswers/ReturnsMoreEmptyValues.html" title="class in org.mockito.internal.stubbing.defaultanswers"><CODE>ReturnsMoreEmptyValues</CODE></A>)
|
|
then it tries to return SmartNull. If the return type is final then plain null is returned.
|
|
<p>
|
|
ReturnsSmartNulls will be probably the default return values strategy in Mockito 2.0
|
|
<p>
|
|
Example:
|
|
<pre>
|
|
Foo mock = (Foo.class, RETURNS_SMART_NULLS);
|
|
|
|
//calling unstubbed method here:
|
|
Stuff stuff = mock.getStuff();
|
|
|
|
//using object returned by unstubbed call:
|
|
stuff.doSomething();
|
|
|
|
//Above doesn't yield NullPointerException this time!
|
|
//Instead, SmartNullPointerException is thrown.
|
|
//Exception's cause links to unstubbed <i>mock.getStuff()</i> - just click on the stack trace.
|
|
</pre>
|
|
<P>
|
|
<DL>
|
|
</DL>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="RETURNS_MOCKS"><!-- --></A><H3>
|
|
RETURNS_MOCKS</H3>
|
|
<PRE>
|
|
public static final <A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing">Answer</A><java.lang.Object> <B>RETURNS_MOCKS</B></PRE>
|
|
<DL>
|
|
<DD>Optional Answer to be used with <A HREF="../../org/mockito/Mockito.html#mock(java.lang.Class, org.mockito.stubbing.Answer)"><CODE>mock(Class, Answer)</CODE></A>
|
|
<p>
|
|
<A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing"><CODE>Answer</CODE></A> can be used to define the return values of unstubbed invocations.
|
|
<p>
|
|
This implementation can be helpful when working with legacy code.
|
|
<p>
|
|
ReturnsMocks first tries to return ordinary return values (see <A HREF="../../org/mockito/internal/stubbing/defaultanswers/ReturnsMoreEmptyValues.html" title="class in org.mockito.internal.stubbing.defaultanswers"><CODE>ReturnsMoreEmptyValues</CODE></A>)
|
|
then it tries to return mocks. If the return type cannot be mocked (e.g. is final) then plain null is returned.
|
|
<p>
|
|
<P>
|
|
<DL>
|
|
</DL>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="RETURNS_DEEP_STUBS"><!-- --></A><H3>
|
|
RETURNS_DEEP_STUBS</H3>
|
|
<PRE>
|
|
public static final <A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing">Answer</A><java.lang.Object> <B>RETURNS_DEEP_STUBS</B></PRE>
|
|
<DL>
|
|
<DD>Optional Answer to be used with <A HREF="../../org/mockito/Mockito.html#mock(java.lang.Class, org.mockito.stubbing.Answer)"><CODE>mock(Class, Answer)</CODE></A>
|
|
<p>
|
|
Example that shows how deep stub works:
|
|
<pre>
|
|
Foo mock = mock(Foo.class, RETURNS_DEEP_STUBS);
|
|
|
|
// note that we're stubbing a chain of methods here: getBar().getName()
|
|
when(mock.getBar().getName()).thenReturn("deep");
|
|
|
|
// note that we're chaining method calls: getBar().getName()
|
|
assertEquals("deep", mock.getBar().getName());
|
|
</pre>
|
|
|
|
<strong>Verification API does not support 'chaining'</strong> so deep stub doesn't change how you do verification.
|
|
<p>
|
|
<strong>WARNING: </strong>
|
|
This feature should rarely be required for regular clean code! Leave it for legacy code.
|
|
Mocking a mock to return a mock, to return a mock, (...), to return something meaningful
|
|
hints at violation of Law of Demeter or mocking a value object (a well known anti-pattern).
|
|
<p>
|
|
Good quote I've seen one day on the web: <strong>every time a mock returns a mock a fairy dies</strong>.
|
|
<p>
|
|
How deep stub work internally?
|
|
<pre>
|
|
//this:
|
|
Foo mock = mock(Foo.class, RETURNS_DEEP_STUBS);
|
|
when(mock.getBar().getName(), "deep");
|
|
|
|
//is equivalent of
|
|
Foo foo = mock(Foo.class);
|
|
Bar bar = mock(Bar.class);
|
|
when(foo.getBar()).thenReturn(bar);
|
|
when(bar.getName()).thenReturn("deep");
|
|
</pre>
|
|
<p>
|
|
This feature will not work when any return type of methods included in the chain cannot be mocked
|
|
(for example: is a primitive or a final class). This is because of java type system.
|
|
<P>
|
|
<DL>
|
|
</DL>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="CALLS_REAL_METHODS"><!-- --></A><H3>
|
|
CALLS_REAL_METHODS</H3>
|
|
<PRE>
|
|
public static final <A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing">Answer</A><java.lang.Object> <B>CALLS_REAL_METHODS</B></PRE>
|
|
<DL>
|
|
<DD>Optional Answer to be used with <A HREF="../../org/mockito/Mockito.html#mock(java.lang.Class, org.mockito.stubbing.Answer)"><CODE>mock(Class, Answer)</CODE></A>
|
|
<p>
|
|
<A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing"><CODE>Answer</CODE></A> can be used to define the return values of unstubbed invocations.
|
|
<p>
|
|
This implementation can be helpful when working with legacy code.
|
|
When this implementation is used, unstubbed methods will delegate to the real implementation.
|
|
This is a way to create a partial mock object that calls real methods by default.
|
|
<p>
|
|
As usual you are going to read <b>the partial mock warning</b>:
|
|
Object oriented programming is more less tackling complexity by dividing the complexity into separate, specific, SRPy objects.
|
|
How does partial mock fit into this paradigm? Well, it just doesn't...
|
|
Partial mock usually means that the complexity has been moved to a different method on the same object.
|
|
In most cases, this is not the way you want to design your application.
|
|
<p>
|
|
However, there are rare cases when partial mocks come handy:
|
|
dealing with code you cannot change easily (3rd party interfaces, interim refactoring of legacy code etc.)
|
|
However, I wouldn't use partial mocks for new, test-driven & well-designed code.
|
|
<p>
|
|
Example:
|
|
<pre>
|
|
Foo mock = mock(Foo.class, CALLS_REAL_METHODS);
|
|
|
|
// this calls the real implementation of Foo.getSomething()
|
|
value = mock.getSomething();
|
|
|
|
when(mock.getSomething()).thenReturn(fakeValue);
|
|
|
|
// now fakeValue is returned
|
|
value = mock.getSomething();
|
|
</pre>
|
|
<P>
|
|
<DL>
|
|
</DL>
|
|
</DL>
|
|
|
|
<!-- ========= CONSTRUCTOR DETAIL ======== -->
|
|
|
|
<A NAME="constructor_detail"><!-- --></A>
|
|
<TABLE BORDER="1" WIDTH="100%" CELLPADDING="3" CELLSPACING="0" SUMMARY="">
|
|
<TR BGCOLOR="#CCCCFF" CLASS="TableHeadingColor">
|
|
<TH ALIGN="left" COLSPAN="1"><FONT SIZE="+2">
|
|
<B>Constructor Detail</B></FONT></TH>
|
|
</TR>
|
|
</TABLE>
|
|
|
|
<A NAME="Mockito()"><!-- --></A><H3>
|
|
Mockito</H3>
|
|
<PRE>
|
|
public <B>Mockito</B>()</PRE>
|
|
<DL>
|
|
</DL>
|
|
|
|
<!-- ============ METHOD DETAIL ========== -->
|
|
|
|
<A NAME="method_detail"><!-- --></A>
|
|
<TABLE BORDER="1" WIDTH="100%" CELLPADDING="3" CELLSPACING="0" SUMMARY="">
|
|
<TR BGCOLOR="#CCCCFF" CLASS="TableHeadingColor">
|
|
<TH ALIGN="left" COLSPAN="1"><FONT SIZE="+2">
|
|
<B>Method Detail</B></FONT></TH>
|
|
</TR>
|
|
</TABLE>
|
|
|
|
<A NAME="mock(java.lang.Class)"><!-- --></A><H3>
|
|
mock</H3>
|
|
<PRE>
|
|
public static <T> T <B>mock</B>(java.lang.Class<T> classToMock)</PRE>
|
|
<DL>
|
|
<DD>Creates mock object of given class or interface.
|
|
<p>
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>classToMock</CODE> - class or interface to mock
|
|
<DT><B>Returns:</B><DD>mock object</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="mock(java.lang.Class, java.lang.String)"><!-- --></A><H3>
|
|
mock</H3>
|
|
<PRE>
|
|
public static <T> T <B>mock</B>(java.lang.Class<T> classToMock,
|
|
java.lang.String name)</PRE>
|
|
<DL>
|
|
<DD>Specifies mock name. Naming mocks can be helpful for debugging - the name is used in all verification errors.
|
|
<p>
|
|
Beware that naming mocks is not a solution for complex code which uses too many mocks or collaborators.
|
|
<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.
|
|
<p>
|
|
<b>If you use @Mock annotation then you've got naming mocks for free!</b> @Mock uses field name as mock name. <A HREF="../../org/mockito/Mock.html" title="annotation in org.mockito"><CODE>Read more.</CODE></A>
|
|
<p>
|
|
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>classToMock</CODE> - class or interface to mock<DD><CODE>name</CODE> - of the mock
|
|
<DT><B>Returns:</B><DD>mock object</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="mock(java.lang.Class, org.mockito.ReturnValues)"><!-- --></A><H3>
|
|
mock</H3>
|
|
<PRE>
|
|
<FONT SIZE="-1">@Deprecated
|
|
</FONT>public static <T> T <B>mock</B>(java.lang.Class<T> classToMock,
|
|
<A HREF="../../org/mockito/ReturnValues.html" title="interface in org.mockito">ReturnValues</A> returnValues)</PRE>
|
|
<DL>
|
|
<DD><B>Deprecated.</B> <I><b>Please use mock(Foo.class, defaultAnswer);</b>
|
|
<p>
|
|
See <A HREF="../../org/mockito/Mockito.html#mock(java.lang.Class, org.mockito.stubbing.Answer)"><CODE>mock(Class, Answer)</CODE></A>
|
|
<p>
|
|
Why it is deprecated? ReturnValues is being replaced by Answer
|
|
for better consistency & interoperability of the framework.
|
|
Answer interface has been in Mockito for a while and it has the same responsibility as ReturnValues.
|
|
There's no point in mainting exactly the same interfaces.
|
|
<p>
|
|
Creates mock with a specified strategy for its return values.
|
|
It's quite advanced feature and typically you don't need it to write decent tests.
|
|
However it can be helpful when working with legacy systems.
|
|
<p>
|
|
Obviously return values are used only when you don't stub the method call.
|
|
|
|
<pre>
|
|
Foo mock = mock(Foo.class, Mockito.RETURNS_SMART_NULLS);
|
|
Foo mockTwo = mock(Foo.class, new YourOwnReturnValues());
|
|
</pre>
|
|
|
|
<p>See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class</p></I>
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>classToMock</CODE> - class or interface to mock<DD><CODE>returnValues</CODE> - default return values for unstubbed methods
|
|
<DT><B>Returns:</B><DD>mock object</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="mock(java.lang.Class, org.mockito.stubbing.Answer)"><!-- --></A><H3>
|
|
mock</H3>
|
|
<PRE>
|
|
public static <T> T <B>mock</B>(java.lang.Class<T> classToMock,
|
|
<A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing">Answer</A> defaultAnswer)</PRE>
|
|
<DL>
|
|
<DD>Creates mock with a specified strategy for its answers to interactions.
|
|
It's quite advanced feature and typically you don't need it to write decent tests.
|
|
However it can be helpful when working with legacy systems.
|
|
<p>
|
|
It is the default answer so it will be used <b>only when you don't</b> stub the method call.
|
|
|
|
<pre>
|
|
Foo mock = mock(Foo.class, RETURNS_SMART_NULLS);
|
|
Foo mockTwo = mock(Foo.class, new YourOwnAnswer());
|
|
</pre>
|
|
|
|
<p>See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class</p>
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>classToMock</CODE> - class or interface to mock<DD><CODE>defaultAnswer</CODE> - default answer for unstubbed methods
|
|
<DT><B>Returns:</B><DD>mock object</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="mock(java.lang.Class, org.mockito.MockSettings)"><!-- --></A><H3>
|
|
mock</H3>
|
|
<PRE>
|
|
public static <T> T <B>mock</B>(java.lang.Class<T> classToMock,
|
|
<A HREF="../../org/mockito/MockSettings.html" title="interface in org.mockito">MockSettings</A> mockSettings)</PRE>
|
|
<DL>
|
|
<DD>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 <A HREF="../../org/mockito/MockSettings.html" title="interface in org.mockito"><CODE>MockSettings</CODE></A>.
|
|
<pre>
|
|
Listener mock = mock(Listener.class, withSettings()
|
|
.name("firstListner").defaultBehavior(RETURNS_SMART_NULLS));
|
|
);
|
|
</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 <A HREF="../../org/mockito/Mockito.html#withSettings()"><CODE>withSettings()</CODE></A>
|
|
<p>
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>classToMock</CODE> - class or interface to mock<DD><CODE>mockSettings</CODE> - additional mock settings
|
|
<DT><B>Returns:</B><DD>mock object</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="spy(java.lang.Object)"><!-- --></A><A NAME="spy(T)"><!-- --></A><H3>
|
|
spy</H3>
|
|
<PRE>
|
|
public static <T> T <B>spy</B>(T object)</PRE>
|
|
<DL>
|
|
<DD>Creates a spy of the real object. The spy calls <b>real</b> methods unless they are stubbed.
|
|
<p>
|
|
Real spies should be used <b>carefully and occasionally</b>, for example when dealing with legacy code.
|
|
<p>
|
|
As usual you are going to read <b>the partial mock warning</b>:
|
|
Object oriented programming is more less tackling complexity by dividing the complexity into separate, specific, SRPy objects.
|
|
How does partial mock fit into this paradigm? Well, it just doesn't...
|
|
Partial mock usually means that the complexity has been moved to a different method on the same object.
|
|
In most cases, this is not the way you want to design your application.
|
|
<p>
|
|
However, there are rare cases when partial mocks come handy:
|
|
dealing with code you cannot change easily (3rd party interfaces, interim refactoring of legacy code etc.)
|
|
However, I wouldn't use partial mocks for new, test-driven & well-designed code.
|
|
<p>
|
|
Example:
|
|
|
|
<pre>
|
|
List list = new LinkedList();
|
|
List spy = spy(list);
|
|
|
|
//optionally, you can stub out some methods:
|
|
when(spy.size()).thenReturn(100);
|
|
|
|
//using the spy calls <b>real</b> methods
|
|
spy.add("one");
|
|
spy.add("two");
|
|
|
|
//prints "one" - the first element of a list
|
|
System.out.println(spy.get(0));
|
|
|
|
//size() method was stubbed - 100 is printed
|
|
System.out.println(spy.size());
|
|
|
|
//optionally, you can verify
|
|
verify(spy).add("one");
|
|
verify(spy).add("two");
|
|
</pre>
|
|
|
|
<h4>Important gotcha on spying real objects!</h4>
|
|
|
|
1. Sometimes it's impossible to use <A HREF="../../org/mockito/Mockito.html#when(T)"><CODE>when(Object)</CODE></A> for stubbing spies. Example:
|
|
|
|
<pre>
|
|
List list = new LinkedList();
|
|
List spy = spy(list);
|
|
|
|
//Impossible: real method is called so spy.get(0) throws IndexOutOfBoundsException (the list is yet empty)
|
|
when(spy.get(0)).thenReturn("foo");
|
|
|
|
//You have to use doReturn() for stubbing
|
|
doReturn("foo").when(spy).get(0);
|
|
</pre>
|
|
|
|
2. Watch out for final methods.
|
|
Mockito doesn't mock final methods so the bottom line is: when you spy on real objects + you try to stub a final method = trouble.
|
|
What will happen is the real method will be called *on mock* but *not on the real instance* you passed to the spy() method.
|
|
Typically you may get a NullPointerException because mock instances don't have fields initiated.
|
|
|
|
<p>
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>object</CODE> - to spy on
|
|
<DT><B>Returns:</B><DD>a spy of the real object</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="stub(java.lang.Object)"><!-- --></A><A NAME="stub(T)"><!-- --></A><H3>
|
|
stub</H3>
|
|
<PRE>
|
|
public static <T> <A HREF="../../org/mockito/stubbing/DeprecatedOngoingStubbing.html" title="interface in org.mockito.stubbing">DeprecatedOngoingStubbing</A><T> <B>stub</B>(T methodCall)</PRE>
|
|
<DL>
|
|
<DD>Stubs a method call with return value or an exception. E.g:
|
|
|
|
<pre>
|
|
stub(mock.someMethod()).toReturn(10);
|
|
|
|
//you can use flexible argument matchers, e.g:
|
|
stub(mock.someMethod(<b>anyString()</b>)).toReturn(10);
|
|
|
|
//setting exception to be thrown:
|
|
stub(mock.someMethod("some arg")).toThrow(new RuntimeException());
|
|
|
|
//you can stub with different behavior for consecutive method calls.
|
|
//Last stubbing (e.g: toReturn("foo")) determines the behavior for further consecutive calls.
|
|
stub(mock.someMethod("some arg"))
|
|
.toThrow(new RuntimeException())
|
|
.toReturn("foo");
|
|
</pre>
|
|
<p>
|
|
Some users find stub() confusing therefore <A HREF="../../org/mockito/Mockito.html#when(T)"><CODE>when(Object)</CODE></A> is recommended over stub()
|
|
<pre>
|
|
//Instead of:
|
|
stub(mock.count()).toReturn(10);
|
|
|
|
//You can do:
|
|
when(mock.count()).thenReturn(10);
|
|
</pre>
|
|
For stubbing void methods with throwables see: <A HREF="../../org/mockito/Mockito.html#doThrow(java.lang.Throwable)"><CODE>doThrow(Throwable)</CODE></A>
|
|
<p>
|
|
Stubbing can be overridden: for example common stubbing can go to fixture
|
|
setup but the test methods can override it.
|
|
Please note that overridding stubbing is a potential code smell that points out too much stubbing.
|
|
<p>
|
|
Once stubbed, the method will always return stubbed value regardless
|
|
of how many times it is called.
|
|
<p>
|
|
Last stubbing is more important - when you stubbed the same method with
|
|
the same arguments many times.
|
|
<p>
|
|
Although it is possible to verify a stubbed invocation, usually <b>it's just redundant</b>.
|
|
Let's say you've stubbed foo.bar().
|
|
If your code cares what foo.bar() returns then something else breaks(often before even verify() gets executed).
|
|
If your code doesn't care what get(0) returns then it should not be stubbed.
|
|
Not convinced? See <a href="http://monkeyisland.pl/2008/04/26/asking-and-telling">here</a>.
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>methodCall</CODE> - method call
|
|
<DT><B>Returns:</B><DD>DeprecatedOngoingStubbing object to set stubbed value/exception</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="when(java.lang.Object)"><!-- --></A><A NAME="when(T)"><!-- --></A><H3>
|
|
when</H3>
|
|
<PRE>
|
|
public static <T> <A HREF="../../org/mockito/stubbing/OngoingStubbing.html" title="interface in org.mockito.stubbing">OngoingStubbing</A><T> <B>when</B>(T methodCall)</PRE>
|
|
<DL>
|
|
<DD>Enables stubbing methods. Use it when you want the mock to return particular value when particular method is called.
|
|
<p>
|
|
Simply put: "<b>When</b> the x method is called <b>then</b> return y".
|
|
<p>
|
|
<b>when() is a successor of deprecated <A HREF="../../org/mockito/Mockito.html#stub(T)"><CODE>stub(Object)</CODE></A></b>
|
|
<p>
|
|
Examples:
|
|
|
|
<pre>
|
|
<b>when</b>(mock.someMethod()).<b>thenReturn</b>(10);
|
|
|
|
//you can use flexible argument matchers, e.g:
|
|
when(mock.someMethod(<b>anyString()</b>)).thenReturn(10);
|
|
|
|
//setting exception to be thrown:
|
|
when(mock.someMethod("some arg")).thenThrow(new RuntimeException());
|
|
|
|
//you can set different behavior for consecutive method calls.
|
|
//Last stubbing (e.g: thenReturn("foo")) determines the behavior of further consecutive calls.
|
|
when(mock.someMethod("some arg"))
|
|
.thenThrow(new RuntimeException())
|
|
.thenReturn("foo");
|
|
|
|
//Alternative, shorter version for consecutive stubbing:
|
|
when(mock.someMethod("some arg"))
|
|
.thenReturn("one", "two");
|
|
//is the same as:
|
|
when(mock.someMethod("some arg"))
|
|
.thenReturn("one")
|
|
.thenReturn("two");
|
|
|
|
//shorter version for consecutive method calls throwing exceptions:
|
|
when(mock.someMethod("some arg"))
|
|
.thenThrow(new RuntimeException(), new NullPointerException();
|
|
|
|
</pre>
|
|
|
|
For stubbing void methods with throwables see: <A HREF="../../org/mockito/Mockito.html#doThrow(java.lang.Throwable)"><CODE>doThrow(Throwable)</CODE></A>
|
|
<p>
|
|
Stubbing can be overridden: for example common stubbing can go to fixture
|
|
setup but the test methods can override it.
|
|
Please note that overridding stubbing is a potential code smell that points out too much stubbing.
|
|
<p>
|
|
Once stubbed, the method will always return stubbed value regardless
|
|
of how many times it is called.
|
|
<p>
|
|
Last stubbing is more important - when you stubbed the same method with
|
|
the same arguments many times.
|
|
<p>
|
|
Although it is possible to verify a stubbed invocation, usually <b>it's just redundant</b>.
|
|
Let's say you've stubbed foo.bar().
|
|
If your code cares what foo.bar() returns then something else breaks(often before even verify() gets executed).
|
|
If your code doesn't care what get(0) 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 <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>methodCall</CODE> - method to be stubbed</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="verify(java.lang.Object)"><!-- --></A><A NAME="verify(T)"><!-- --></A><H3>
|
|
verify</H3>
|
|
<PRE>
|
|
public static <T> T <B>verify</B>(T mock)</PRE>
|
|
<DL>
|
|
<DD>Verifies certain behavior <b>happened once</b>
|
|
<p>
|
|
Alias to <code>verify(mock, times(1))</code> E.g:
|
|
<pre>
|
|
verify(mock).someMethod("some arg");
|
|
</pre>
|
|
Above is equivalent to:
|
|
<pre>
|
|
verify(mock, times(1)).someMethod("some arg");
|
|
</pre>
|
|
<p>
|
|
Arguments passed are compared using equals() method.
|
|
Read about <A HREF="../../org/mockito/ArgumentCaptor.html" title="class in org.mockito"><CODE>ArgumentCaptor</CODE></A> or <A HREF="../../org/mockito/ArgumentMatcher.html" title="class in org.mockito"><CODE>ArgumentMatcher</CODE></A> 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 foo.bar().
|
|
If your code cares what foo.bar() returns then something else breaks(often before even verify() gets executed).
|
|
If your code doesn't care what get(0) 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 <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>mock</CODE> - to be verified
|
|
<DT><B>Returns:</B><DD>mock object itself</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="verify(java.lang.Object,org.mockito.verification.VerificationMode)"><!-- --></A><A NAME="verify(T, org.mockito.verification.VerificationMode)"><!-- --></A><H3>
|
|
verify</H3>
|
|
<PRE>
|
|
public static <T> T <B>verify</B>(T mock,
|
|
<A HREF="../../org/mockito/verification/VerificationMode.html" title="interface in org.mockito.verification">VerificationMode</A> mode)</PRE>
|
|
<DL>
|
|
<DD>Verifies certain behavior happened at least once / exact number of times / never. E.g:
|
|
<pre>
|
|
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>);
|
|
</pre>
|
|
|
|
<b>times(1) is the default</b> and can be omitted
|
|
<p>
|
|
Arguments passed are compared using equals() method.
|
|
Read about <A HREF="../../org/mockito/ArgumentCaptor.html" title="class in org.mockito"><CODE>ArgumentCaptor</CODE></A> or <A HREF="../../org/mockito/ArgumentMatcher.html" title="class in org.mockito"><CODE>ArgumentMatcher</CODE></A> to find out other ways of matching / asserting arguments passed.
|
|
<p>
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>mock</CODE> - to be verified<DD><CODE>mode</CODE> - times(x), atLeastOnce() or never()
|
|
<DT><B>Returns:</B><DD>mock object itself</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="reset(java.lang.Object)"><!-- --></A><A NAME="reset(T...)"><!-- --></A><H3>
|
|
reset</H3>
|
|
<PRE>
|
|
public static <T> void <B>reset</B>(T... mocks)</PRE>
|
|
<DL>
|
|
<DD>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 reset() please consider writing simple, small and focused test methods over lengthy, over-specified tests.
|
|
<b>First potential code smell is reset() 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 reset() 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> reset() in the middle of the test method is a code smell (you're probably testing too much).
|
|
<pre>
|
|
List mock = mock(List.class);
|
|
when(mock.size()).thenReturn(10);
|
|
mock.add(1);
|
|
|
|
reset(mock);
|
|
//at this point the mock forgot any interactions & stubbing
|
|
</pre>
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Type Parameters:</B><DD><CODE>T</CODE> - <DT><B>Parameters:</B><DD><CODE>mocks</CODE> - to be reset</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="verifyNoMoreInteractions(java.lang.Object...)"><!-- --></A><H3>
|
|
verifyNoMoreInteractions</H3>
|
|
<PRE>
|
|
public static void <B>verifyNoMoreInteractions</B>(java.lang.Object... mocks)</PRE>
|
|
<DL>
|
|
<DD>Checks if any of given mocks has any unverified interaction.
|
|
<p>
|
|
You can use this method after you verified your mocks - to make sure that nothing
|
|
else was invoked on your mocks.
|
|
<p>
|
|
See also <A HREF="../../org/mockito/Mockito.html#never()"><CODE>never()</CODE></A> - it is more explicit and communicates the intent well.
|
|
<p>
|
|
Stubbed invocations (if called) are also treated as interactions.
|
|
<p>
|
|
A word of <b>warning</b>:
|
|
Some users who did a lot of classic, expect-run-verify mocking tend to use verifyNoMoreInteractions() very often, even in every test method.
|
|
verifyNoMoreInteractions() is not recommended to use in every test method.
|
|
verifyNoMoreInteractions() is a handy assertion from the interaction testing toolkit. Use it only when it's relevant.
|
|
Abusing it leads to overspecified, less maintainable tests. You can find further reading
|
|
<a href="http://monkeyisland.pl/2008/07/12/should-i-worry-about-the-unexpected/">here</a>.
|
|
<p>
|
|
This method will also detect unverified invocations that occurred before the test method,
|
|
for example: in setUp(), @Before method or in constructor.
|
|
Consider writing nice code that makes interactions only in test methods.
|
|
|
|
<p>
|
|
Example:
|
|
|
|
<pre>
|
|
//interactions
|
|
mock.doSomething();
|
|
mock.doSomethingUnexpected();
|
|
|
|
//verification
|
|
verify(mock).doSomething();
|
|
|
|
//following will fail because 'doSomethingUnexpected()' is unexpected
|
|
verifyNoMoreInteractions(mock);
|
|
|
|
</pre>
|
|
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>mocks</CODE> - to be verified</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="verifyZeroInteractions(java.lang.Object...)"><!-- --></A><H3>
|
|
verifyZeroInteractions</H3>
|
|
<PRE>
|
|
public static void <B>verifyZeroInteractions</B>(java.lang.Object... mocks)</PRE>
|
|
<DL>
|
|
<DD>Verifies that no interactions happened on given mocks.
|
|
<pre>
|
|
verifyZeroInteractions(mockOne, mockTwo);
|
|
</pre>
|
|
This method will also detect invocations
|
|
that occurred before the test method, for example: in setUp(), @Before method or in constructor.
|
|
Consider writing nice code that makes interactions only in test methods.
|
|
<p>
|
|
See also <A HREF="../../org/mockito/Mockito.html#never()"><CODE>never()</CODE></A> - it is more explicit and communicates the intent well.
|
|
<p>
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>mocks</CODE> - to be verified</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="stubVoid(java.lang.Object)"><!-- --></A><A NAME="stubVoid(T)"><!-- --></A><H3>
|
|
stubVoid</H3>
|
|
<PRE>
|
|
public static <T> <A HREF="../../org/mockito/stubbing/VoidMethodStubbable.html" title="interface in org.mockito.stubbing">VoidMethodStubbable</A><T> <B>stubVoid</B>(T mock)</PRE>
|
|
<DL>
|
|
<DD><B>Deprecated.</B> <I>Use <A HREF="../../org/mockito/Mockito.html#doThrow(java.lang.Throwable)"><CODE>doThrow(Throwable)</CODE></A> method for stubbing voids</I>
|
|
<P>
|
|
<DD><pre>
|
|
//Instead of:
|
|
stubVoid(mock).toThrow(e).on().someVoidMethod();
|
|
|
|
//Please do:
|
|
doThrow(e).when(mock).someVoidMethod();
|
|
</pre>
|
|
|
|
doThrow() replaces stubVoid() because of improved readability and consistency with the family of doAnswer() methods.
|
|
<p>
|
|
Originally, stubVoid() was used for stubbing void methods with exceptions. E.g:
|
|
|
|
<pre>
|
|
stubVoid(mock).toThrow(new RuntimeException()).on().someMethod();
|
|
|
|
//you can stub with different behavior for consecutive calls.
|
|
//Last stubbing (e.g. toReturn()) determines the behavior for further consecutive calls.
|
|
stubVoid(mock)
|
|
.toThrow(new RuntimeException())
|
|
.toReturn()
|
|
.on().someMethod();
|
|
</pre>
|
|
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>mock</CODE> - to stub
|
|
<DT><B>Returns:</B><DD>stubbable object that allows stubbing with throwable</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="doThrow(java.lang.Throwable)"><!-- --></A><H3>
|
|
doThrow</H3>
|
|
<PRE>
|
|
public static <A HREF="../../org/mockito/stubbing/Stubber.html" title="interface in org.mockito.stubbing">Stubber</A> <B>doThrow</B>(java.lang.Throwable toBeThrown)</PRE>
|
|
<DL>
|
|
<DD>Use doThrow() when you want to stub the void method with an exception.
|
|
<p>
|
|
Stubbing voids requires different approach from <A HREF="../../org/mockito/Mockito.html#when(T)"><CODE>when(Object)</CODE></A> because the compiler does not like void methods inside brackets...
|
|
<p>
|
|
Example:
|
|
|
|
<pre>
|
|
doThrow(new RuntimeException()).when(mock).someVoidMethod();
|
|
</pre>
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>toBeThrown</CODE> - to be thrown when the stubbed method is called
|
|
<DT><B>Returns:</B><DD>stubber - to select a method for stubbing</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="doCallRealMethod()"><!-- --></A><H3>
|
|
doCallRealMethod</H3>
|
|
<PRE>
|
|
public static <A HREF="../../org/mockito/stubbing/Stubber.html" title="interface in org.mockito.stubbing">Stubber</A> <B>doCallRealMethod</B>()</PRE>
|
|
<DL>
|
|
<DD>Use doCallRealMethod() when you want to call the real implementation of a method.
|
|
<p>
|
|
As usual you are going to read <b>the partial mock warning</b>:
|
|
Object oriented programming is more less tackling complexity by dividing the complexity into separate, specific, SRPy objects.
|
|
How does partial mock fit into this paradigm? Well, it just doesn't...
|
|
Partial mock usually means that the complexity has been moved to a different method on the same object.
|
|
In most cases, this is not the way you want to design your application.
|
|
<p>
|
|
However, there are rare cases when partial mocks come handy:
|
|
dealing with code you cannot change easily (3rd party interfaces, interim refactoring of legacy code etc.)
|
|
However, I wouldn't use partial mocks for new, test-driven & well-designed code.
|
|
<p>
|
|
See also javadoc <A HREF="../../org/mockito/Mockito.html#spy(T)"><CODE>spy(Object)</CODE></A> to find out more about partial mocks.
|
|
<b>Mockito.spy() is a recommended way of creating partial mocks.</b>
|
|
The reason is it guarantees real methods are called against correctly constructed object because you're responsible for constructing the object passed to spy() method.
|
|
<p>
|
|
Example:
|
|
<pre>
|
|
Foo mock = mock(Foo.class);
|
|
doCallRealMethod().when(mock).someVoidMethod();
|
|
|
|
// this will call the real implementation of Foo.someVoidMethod()
|
|
mock.someVoidMethod();
|
|
</pre>
|
|
<p>
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
|
|
<DT><B>Returns:</B><DD>stubber - to select a method for stubbing</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="doAnswer(org.mockito.stubbing.Answer)"><!-- --></A><H3>
|
|
doAnswer</H3>
|
|
<PRE>
|
|
public static <A HREF="../../org/mockito/stubbing/Stubber.html" title="interface in org.mockito.stubbing">Stubber</A> <B>doAnswer</B>(<A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing">Answer</A> answer)</PRE>
|
|
<DL>
|
|
<DD>Use doAnswer() when you want to stub a void method with generic <A HREF="../../org/mockito/stubbing/Answer.html" title="interface in org.mockito.stubbing"><CODE>Answer</CODE></A>.
|
|
<p>
|
|
Stubbing voids requires different approach from <A HREF="../../org/mockito/Mockito.html#when(T)"><CODE>when(Object)</CODE></A> because the compiler does not like void methods inside brackets...
|
|
<p>
|
|
Example:
|
|
|
|
<pre>
|
|
doAnswer(new Answer() {
|
|
public Object answer(InvocationOnMock invocation) {
|
|
Object[] args = invocation.getArguments();
|
|
Mock mock = invocation.getMock();
|
|
return null;
|
|
}})
|
|
.when(mock).someMethod();
|
|
</pre>
|
|
<p>
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>answer</CODE> - to answer when the stubbed method is called
|
|
<DT><B>Returns:</B><DD>stubber - to select a method for stubbing</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="doNothing()"><!-- --></A><H3>
|
|
doNothing</H3>
|
|
<PRE>
|
|
public static <A HREF="../../org/mockito/stubbing/Stubber.html" title="interface in org.mockito.stubbing">Stubber</A> <B>doNothing</B>()</PRE>
|
|
<DL>
|
|
<DD>Use doNothing() for setting void methods to do nothing. <b>Beware that void methods on mocks do nothing by default!</b>
|
|
However, there are rare situations when doNothing() comes handy:
|
|
<p>
|
|
1. Stubbing consecutive calls on a void method:
|
|
<pre>
|
|
doNothing().
|
|
doThrow(new RuntimeException())
|
|
.when(mock).someVoidMethod();
|
|
|
|
//does nothing the first time:
|
|
mock.someVoidMethod();
|
|
|
|
//throws RuntimeException the next time:
|
|
mock.someVoidMethod();
|
|
</pre>
|
|
|
|
2. When you spy real objects and you want the void method to do nothing:
|
|
<pre>
|
|
List list = new LinkedList();
|
|
List spy = spy(list);
|
|
|
|
//let's make clear() do nothing
|
|
doNothing().when(spy).clear();
|
|
|
|
spy.add("one");
|
|
|
|
//clear() does nothing, so the list still contains "one"
|
|
spy.clear();
|
|
</pre>
|
|
<p>
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
|
|
<DT><B>Returns:</B><DD>stubber - to select a method for stubbing</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="doReturn(java.lang.Object)"><!-- --></A><H3>
|
|
doReturn</H3>
|
|
<PRE>
|
|
public static <A HREF="../../org/mockito/stubbing/Stubber.html" title="interface in org.mockito.stubbing">Stubber</A> <B>doReturn</B>(java.lang.Object toBeReturned)</PRE>
|
|
<DL>
|
|
<DD>Use doReturn() in those rare occasions when you cannot use <A HREF="../../org/mockito/Mockito.html#when(T)"><CODE>when(Object)</CODE></A>.
|
|
<p>
|
|
<b>Beware that <A HREF="../../org/mockito/Mockito.html#when(T)"><CODE>when(Object)</CODE></A> is always recommended for stubbing because it is argument type-safe
|
|
and more readable</b> (especially when stubbing consecutive calls).
|
|
<p>
|
|
Here are those rare occasions when doReturn() comes handy:
|
|
<p>
|
|
|
|
1. When spying real objects and calling real methods on a spy brings side effects
|
|
|
|
<pre>
|
|
List list = new LinkedList();
|
|
List spy = spy(list);
|
|
|
|
//Impossible: real method is called so spy.get(0) throws IndexOutOfBoundsException (the list is yet empty)
|
|
when(spy.get(0)).thenReturn("foo");
|
|
|
|
//You have to use doReturn() for stubbing:
|
|
doReturn("foo").when(spy).get(0);
|
|
</pre>
|
|
|
|
2. Overriding a previous exception-stubbing:
|
|
|
|
<pre>
|
|
when(mock.foo()).thenThrow(new RuntimeException());
|
|
|
|
//Impossible: the exception-stubbed foo() method is called so RuntimeException is thrown.
|
|
when(mock.foo()).thenReturn("bar");
|
|
|
|
//You have to use doReturn() for stubbing:
|
|
doReturn("bar").when(mock).foo();
|
|
</pre>
|
|
|
|
Above scenarios shows a tradeoff of Mockito's ellegant syntax. Note that the scenarios are very rare, though.
|
|
Spying should be sporadic and overriding exception-stubbing is very rare. Not to mention that in general
|
|
overridding stubbing is a potential code smell that points out too much stubbing.
|
|
<p>
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>toBeReturned</CODE> - to be returned when the stubbed method is called
|
|
<DT><B>Returns:</B><DD>stubber - to select a method for stubbing</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="inOrder(java.lang.Object...)"><!-- --></A><H3>
|
|
inOrder</H3>
|
|
<PRE>
|
|
public static <A HREF="../../org/mockito/InOrder.html" title="interface in org.mockito">InOrder</A> <B>inOrder</B>(java.lang.Object... mocks)</PRE>
|
|
<DL>
|
|
<DD>Creates InOrder object that allows verifying mocks in order.
|
|
|
|
<pre>
|
|
InOrder inOrder = inOrder(firstMock, secondMock);
|
|
|
|
inOrder.verify(firstMock).add("was called first");
|
|
inOrder.verify(secondMock).add("was called second");
|
|
</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>
|
|
InOrder 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: <A HREF="../../org/mockito/InOrder.html#verifyNoMoreInteractions()"><CODE>InOrder.verifyNoMoreInteractions()</CODE></A>
|
|
<p>
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>mocks</CODE> - to be verified in order
|
|
<DT><B>Returns:</B><DD>InOrder object to be used to verify in order</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="times(int)"><!-- --></A><H3>
|
|
times</H3>
|
|
<PRE>
|
|
public static <A HREF="../../org/mockito/verification/VerificationMode.html" title="interface in org.mockito.verification">VerificationMode</A> <B>times</B>(int wantedNumberOfInvocations)</PRE>
|
|
<DL>
|
|
<DD>Allows verifying exact number of invocations. E.g:
|
|
<pre>
|
|
verify(mock, times(2)).someMethod("some arg");
|
|
</pre>
|
|
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>wantedNumberOfInvocations</CODE> - wanted number of invocations
|
|
<DT><B>Returns:</B><DD>verification mode</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="never()"><!-- --></A><H3>
|
|
never</H3>
|
|
<PRE>
|
|
public static <A HREF="../../org/mockito/verification/VerificationMode.html" title="interface in org.mockito.verification">VerificationMode</A> <B>never</B>()</PRE>
|
|
<DL>
|
|
<DD>Alias to times(0), see <A HREF="../../org/mockito/Mockito.html#times(int)"><CODE>times(int)</CODE></A>
|
|
<p>
|
|
Verifies that interaction did not happen. E.g:
|
|
<pre>
|
|
verify(mock, never()).someMethod();
|
|
</pre>
|
|
|
|
<p>
|
|
If you want to verify there were NO interactions with the mock
|
|
check out <A HREF="../../org/mockito/Mockito.html#verifyZeroInteractions(java.lang.Object...)"><CODE>verifyZeroInteractions(Object...)</CODE></A>
|
|
or <A HREF="../../org/mockito/Mockito.html#verifyNoMoreInteractions(java.lang.Object...)"><CODE>verifyNoMoreInteractions(Object...)</CODE></A>
|
|
<p>
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
|
|
<DT><B>Returns:</B><DD>verification mode</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="atLeastOnce()"><!-- --></A><H3>
|
|
atLeastOnce</H3>
|
|
<PRE>
|
|
public static <A HREF="../../org/mockito/verification/VerificationMode.html" title="interface in org.mockito.verification">VerificationMode</A> <B>atLeastOnce</B>()</PRE>
|
|
<DL>
|
|
<DD>Allows at-least-once verification. E.g:
|
|
<pre>
|
|
verify(mock, atLeastOnce()).someMethod("some arg");
|
|
</pre>
|
|
Alias to atLeast(1)
|
|
<p>
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
|
|
<DT><B>Returns:</B><DD>verification mode</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="atLeast(int)"><!-- --></A><H3>
|
|
atLeast</H3>
|
|
<PRE>
|
|
public static <A HREF="../../org/mockito/verification/VerificationMode.html" title="interface in org.mockito.verification">VerificationMode</A> <B>atLeast</B>(int minNumberOfInvocations)</PRE>
|
|
<DL>
|
|
<DD>Allows at-least-x verification. E.g:
|
|
<pre>
|
|
verify(mock, atLeast(3)).someMethod("some arg");
|
|
</pre>
|
|
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>minNumberOfInvocations</CODE> - minimum number of invocations
|
|
<DT><B>Returns:</B><DD>verification mode</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="atMost(int)"><!-- --></A><H3>
|
|
atMost</H3>
|
|
<PRE>
|
|
public static <A HREF="../../org/mockito/verification/VerificationMode.html" title="interface in org.mockito.verification">VerificationMode</A> <B>atMost</B>(int maxNumberOfInvocations)</PRE>
|
|
<DL>
|
|
<DD>Allows at-most-x verification. E.g:
|
|
<pre>
|
|
verify(mock, atMost(3)).someMethod("some arg");
|
|
</pre>
|
|
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>maxNumberOfInvocations</CODE> - max number of invocations
|
|
<DT><B>Returns:</B><DD>verification mode</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="only()"><!-- --></A><H3>
|
|
only</H3>
|
|
<PRE>
|
|
public static <A HREF="../../org/mockito/verification/VerificationMode.html" title="interface in org.mockito.verification">VerificationMode</A> <B>only</B>()</PRE>
|
|
<DL>
|
|
<DD>Allows checking if given method was the only one invoked. E.g:
|
|
<pre>
|
|
verify(mock, only()).someMethod();
|
|
//above is a shorthand for following 2 lines of code:
|
|
verify(mock).someMethod();
|
|
verifyNoMoreInvocations(mock);
|
|
</pre>
|
|
|
|
<p>
|
|
See also <A HREF="../../org/mockito/Mockito.html#verifyNoMoreInteractions(java.lang.Object...)"><CODE>verifyNoMoreInteractions(Object...)</CODE></A>
|
|
<p>
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
|
|
<DT><B>Returns:</B><DD>verification mode</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="timeout(int)"><!-- --></A><H3>
|
|
timeout</H3>
|
|
<PRE>
|
|
public static <A HREF="../../org/mockito/verification/VerificationWithTimeout.html" title="interface in org.mockito.verification">VerificationWithTimeout</A> <B>timeout</B>(int millis)</PRE>
|
|
<DL>
|
|
<DD>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 <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
<DT><B>Parameters:</B><DD><CODE>millis</CODE> - - time span in millis
|
|
<DT><B>Returns:</B><DD>verification mode</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="validateMockitoUsage()"><!-- --></A><H3>
|
|
validateMockitoUsage</H3>
|
|
<PRE>
|
|
public static void <B>validateMockitoUsage</B>()</PRE>
|
|
<DL>
|
|
<DD>First of all, in case of any trouble, I encourage you to read the Mockito FAQ: <a href="http://code.google.com/p/mockito/wiki/FAQ">http://code.google.com/p/mockito/wiki/FAQ</a>
|
|
<p>
|
|
In case of questions you may also post to mockito mailing list: <a href="http://groups.google.com/group/mockito">http://groups.google.com/group/mockito</a>
|
|
<p>
|
|
validateMockitoUsage() <b>explicitly validates</b> the framework state to detect invalid use of Mockito.
|
|
However, this feature is optional <b>because Mockito validates the usage all the time...</b> but there is a gotcha so read on.
|
|
<p>
|
|
Examples of incorrect use:
|
|
<pre>
|
|
//Oups, someone forgot thenReturn() part:
|
|
when(mock.get());
|
|
|
|
//Oups, someone put the verified method call inside verify() where it should be outside:
|
|
verify(mock.execute());
|
|
|
|
//Oups, someone has used EasyMock for too long and forgot to specify the method to verify:
|
|
verify(mock);
|
|
</pre>
|
|
|
|
Mockito throws exceptions if you misuse it so that you know if your tests are written correctly.
|
|
The gotcha is that Mockito does the validation <b>next time</b> you use the framework (e.g. next time you verify, stub, call mock etc.).
|
|
But even though the exception might be thrown in the next test,
|
|
the exception <b>message contains a navigable stack trace element</b> with location of the defect.
|
|
Hence you can click and find the place where Mockito was misused.
|
|
<p>
|
|
Sometimes though, you might want to validate the framework usage explicitly.
|
|
For example, one of the users wanted to put validateMockitoUsage() in his @After method
|
|
so that he knows immediately when he misused Mockito.
|
|
Without it, he would have known about it not sooner than <b>next time</b> he used the framework.
|
|
One more benefit of having validateMockitoUsage() in @After is that jUnit runner will always fail in the test method with defect
|
|
whereas ordinary 'next-time' validation might fail the <b>next</b> test method.
|
|
But even though JUnit might report next test as red, don't worry about it
|
|
and just click at navigable stack trace element in the exception message to instantly locate the place where you misused mockito.
|
|
<p>
|
|
<b>Built-in runner: <A HREF="../../org/mockito/runners/MockitoJUnitRunner.html" title="class in org.mockito.runners"><CODE>MockitoJUnitRunner</CODE></A></b> does validateMockitoUsage() after each test method.
|
|
<p>
|
|
Bear in mind that <b>usually you don't have to validateMockitoUsage()</b>
|
|
and framework validation triggered on next-time basis should be just enough,
|
|
mainly because of enhanced exception message with clickable location of defect.
|
|
However, I would recommend validateMockitoUsage() if you already have sufficient test infrastructure
|
|
(like your own runner or base class for all tests) because adding a special action to @After has zero cost.
|
|
<p>
|
|
See examples in javadoc for <A HREF="../../org/mockito/Mockito.html" title="class in org.mockito"><CODE>Mockito</CODE></A> class
|
|
<P>
|
|
<DD><DL>
|
|
</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
|
|
<A NAME="withSettings()"><!-- --></A><H3>
|
|
withSettings</H3>
|
|
<PRE>
|
|
public static <A HREF="../../org/mockito/MockSettings.html" title="interface in org.mockito">MockSettings</A> <B>withSettings</B>()</PRE>
|
|
<DL>
|
|
<DD>Allows mock creation with additional mock settings.
|
|
<p>
|
|
Don't use it too often.
|
|
Consider writing simple tests that use simple mocks.
|
|
Repeat after me: simple tests push simple, KISSy, readable & maintainable code.
|
|
If you cannot write a test in a simple way - refactor the code under test.
|
|
<p>
|
|
Examples of mock settings:
|
|
<pre>
|
|
//Creates mock with different default answer & name
|
|
Foo mock = mock(Foo.class, withSettings()
|
|
.defaultAnswer(RETURNS_SMART_NULLS)
|
|
.name("cool mockie"));
|
|
|
|
//Creates mock with different default answer, descriptive name and extra interfaces
|
|
Foo mock = mock(Foo.class, withSettings()
|
|
.defaultAnswer(RETURNS_SMART_NULLS)
|
|
.name("cool mockie")
|
|
.extraInterfaces(Bar.class));
|
|
</pre>
|
|
<A HREF="../../org/mockito/MockSettings.html" title="interface in org.mockito"><CODE>MockSettings</CODE></A> has been introduced for two reasons.
|
|
Firstly, to make it easy to add another mock settings when the demand comes.
|
|
Secondly, to enable combining different mock settings without introducing zillions of overloaded mock() methods.
|
|
<p>
|
|
See javadoc for <A HREF="../../org/mockito/MockSettings.html" title="interface in org.mockito"><CODE>MockSettings</CODE></A> to learn about possible mock settings.
|
|
<p>
|
|
<P>
|
|
<DD><DL>
|
|
|
|
<DT><B>Returns:</B><DD>mock settings instance with defaults.</DL>
|
|
</DD>
|
|
</DL>
|
|
<!-- ========= END OF CLASS DATA ========= -->
|
|
<HR>
|
|
|
|
|
|
<!-- ======= START OF BOTTOM NAVBAR ====== -->
|
|
<A NAME="navbar_bottom"><!-- --></A>
|
|
<A HREF="#skip-navbar_bottom" title="Skip navigation links"></A>
|
|
<TABLE BORDER="0" WIDTH="100%" CELLPADDING="1" CELLSPACING="0" SUMMARY="">
|
|
<TR>
|
|
<TD COLSPAN=2 BGCOLOR="#EEEEFF" CLASS="NavBarCell1">
|
|
<A NAME="navbar_bottom_firstrow"><!-- --></A>
|
|
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="3" SUMMARY="">
|
|
<TR ALIGN="center" VALIGN="top">
|
|
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../overview-summary.html"><FONT CLASS="NavBarFont1"><B>Overview</B></FONT></A> </TD>
|
|
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="package-summary.html"><FONT CLASS="NavBarFont1"><B>Package</B></FONT></A> </TD>
|
|
<TD BGCOLOR="#FFFFFF" CLASS="NavBarCell1Rev"> <FONT CLASS="NavBarFont1Rev"><B>Class</B></FONT> </TD>
|
|
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="class-use/Mockito.html"><FONT CLASS="NavBarFont1"><B>Use</B></FONT></A> </TD>
|
|
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="package-tree.html"><FONT CLASS="NavBarFont1"><B>Tree</B></FONT></A> </TD>
|
|
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../deprecated-list.html"><FONT CLASS="NavBarFont1"><B>Deprecated</B></FONT></A> </TD>
|
|
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../index-all.html"><FONT CLASS="NavBarFont1"><B>Index</B></FONT></A> </TD>
|
|
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../help-doc.html"><FONT CLASS="NavBarFont1"><B>Help</B></FONT></A> </TD>
|
|
</TR>
|
|
</TABLE>
|
|
</TD>
|
|
<TD ALIGN="right" VALIGN="top" ROWSPAN=3><EM>
|
|
</EM>
|
|
</TD>
|
|
</TR>
|
|
|
|
<TR>
|
|
<TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">
|
|
<A HREF="../../org/mockito/Mock.html" title="annotation in org.mockito"><B>PREV CLASS</B></A>
|
|
<A HREF="../../org/mockito/MockitoAnnotations.html" title="class in org.mockito"><B>NEXT CLASS</B></A></FONT></TD>
|
|
<TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">
|
|
<A HREF="../../index.html?org/mockito/Mockito.html" target="_top"><B>FRAMES</B></A>
|
|
<A HREF="Mockito.html" target="_top"><B>NO FRAMES</B></A>
|
|
<SCRIPT type="text/javascript">
|
|
<!--
|
|
if(window==top) {
|
|
document.writeln('<A HREF="../../allclasses-noframe.html"><B>All Classes</B></A>');
|
|
}
|
|
//-->
|
|
</SCRIPT>
|
|
<NOSCRIPT>
|
|
<A HREF="../../allclasses-noframe.html"><B>All Classes</B></A>
|
|
</NOSCRIPT>
|
|
|
|
|
|
</FONT></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">
|
|
SUMMARY: NESTED | <A HREF="#field_summary">FIELD</A> | <A HREF="#constructor_summary">CONSTR</A> | <A HREF="#method_summary">METHOD</A></FONT></TD>
|
|
<TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">
|
|
DETAIL: <A HREF="#field_detail">FIELD</A> | <A HREF="#constructor_detail">CONSTR</A> | <A HREF="#method_detail">METHOD</A></FONT></TD>
|
|
</TR>
|
|
</TABLE>
|
|
<A NAME="skip-navbar_bottom"></A>
|
|
<!-- ======== END OF BOTTOM NAVBAR ======= -->
|
|
|
|
<HR>
|
|
|
|
</BODY>
|
|
</HTML>
|