<dependency>\n <groupId>org.mockito<\/groupId>\n <artifactId>mockito-all<\/artifactId>\n <version>1.10.19<\/version>\n<\/dependency><\/pre>\n3.2.2. Gradle<\/h4>\n
Declare the dependency as it is shown below:<\/p>\n
repositories {\n jcenter()\n}\n\ndependencies {\n testCompile \"org.mockito:mockito-core:1.+\"\n}<\/pre>\n4. Base code to test<\/h2>\n
Let’s suppose that our application is for authenticating users, and that our job is to develop the interface that the final user will use, and that developing the logic is someone else’s job. For mocking, is indispensable to agree the interfaces to mock, that is, the method definitions: name, parameters, and return type. For this case, the agreed interface will be a public method authenticateUser<\/code>, that receives two strings, the user name and the password; returning a boolean indicating if the authentication succeeded or not. So, the interface would be the following:<\/p>\nAuthenticatorInterface.java<\/em><\/span><\/p>\npackage com.javacodegeeks.mockitotutorial.basecode;\n\npublic interface AuthenticatorInterface {\n\n \/**\n * User authentication method definition.\n *\n * @param username The user name to authenticate.\n * @param password The password to authenticate the user.\n * @return True if the user has been authenticated; false if it has not.\n * @throws EmptyCredentialsException If the received credentials (user name, password) are\n * empty.\n *\/\n public boolean authenticateUser(String username, String password);\n\n}<\/pre>\nAnd the source that uses this interface:<\/p>\n
AuthenticatorApplication.java<\/em><\/span><\/p>\npackage com.javacodegeeks.mockitotutorial.basecode;\n\npublic class AuthenticatorApplication {\n\n private AuthenticatorInterface authenticator;\n\n \/**\n * AuthenticatorApplication constructor.\n *\n * @param authenticator Authenticator interface implementation.\n *\/\n public AuthenticatorApplication(AuthenticatorInterface authenticator) {\n this.authenticator = authenticator;\n }\n\n \/**\n * Tries to authenticate an user with the received user name and password, with the received\n * AuthenticatorInterface interface implementation in the constructor.\n *\n * @param username The user name to authenticate.\n * @param password The password to authenticate the user.\n * @return True if the user has been authenticated; false if it has not.\n *\/\n public boolean authenticate(String username, String password) {\n boolean authenticated;\n \n authenticated = this.authenticator.authenticateUser(username, password);\n \n return authenticated;\n }\n}<\/pre>\nWe will suppose that this piece of code also implements the main<\/code> method, but is not important for this example.<\/p>\nNow, we are going to code the tests for AuthenticatorApplication<\/code>. The testing method returns a boolean, so we will code tests for covering both possible cases: failed login, and succeeded one.<\/p>\nAs the code that handles the authentication is not developed, we have to make some suppositions. We are not doing any real authentication. We have to define for which values the function will succeed, and for which not.<\/p>\n
5. Adding behavior<\/h2>\n
Let’s see how we can mock the Authenticator:<\/p>\n
AuthenticatorApplicationTest.java<\/em><\/span><\/p>\npackage com.javacodegeeks.mockitotutorial.basecode;\n\nimport org.junit.Test;\nimport org.mockito.Mockito;\n\nimport static org.junit.Assert.*;\nimport static org.mockito.Mockito.*;\n\npublic class AuthenticatorApplicationTest {\n\n @Test\n public void testAuthenticate() {\n AuthenticatorInterface authenticatorMock;\n AuthenticatorApplication authenticator;\n String username = \"JavaCodeGeeks\";\n String password = \"unsafePassword\";\n \n authenticatorMock = Mockito.mock(AuthenticatorInterface.class);\n authenticator = new AuthenticatorApplication(authenticatorMock);\n \n when(authenticatorMock.authenticateUser(username, password))\n .thenReturn(false);\n \n boolean actual = authenticator.authenticate(username, password);\n \n assertFalse(actual);\n }\n}<\/pre>\nLet’s see carefully what we are doing:
<\/div> <\/div><\/p>\n
\n- We import the required stuff, as in lines 4 and 7. The IDE will help us to do it.<\/li>\n
- We define the mock object, in line 18. This is how the mock “learns” the method definitions to mock.<\/li>\n
- The key part is when we add the behavior<\/strong>, as in lines 21 and 22, with the
when()<\/code> and thenReturn()<\/code> functions. Is quite expressive: “When<\/strong> the mock object is called for this method with this parameters, then<\/strong> it returns this value<\/em>“. Note that we are defining the behavior in the mock object, not to the class calling the mock object<\/strong>.<\/li>\n<\/ul>\nAs we are adding the behavior to the reference that has been passed to AuthenticatorApplication<\/code> instance, it doesn’t matter if we first add the behavior and then we pass the reference, or reverse.<\/p>\nWhen the AuthenticatorApplication<\/code> calls to its AuthenticatorInterface<\/code>, it won’t know what is actually happening, the only thing it knows is just how to deal with the defined interface, which for this case has been designed to return false<\/code> when it receives \"JavaCodeGeeks\"<\/code> and \"unsafePassword\"<\/code> as inputs.<\/p>\n6. Verifying behavior<\/h2>\n
Mockito allows to make several verifications about our mock objects. Let’s see which are they.<\/p>\n
6.1. Verify that method has been called<\/h3>\n
We can check if a method has been called with certain parameters. For that, we would do something similar to the following:<\/p>\n
AuthenticatorApplicationTest.java<\/em><\/span><\/p>\n\/\/ ...\n\nverify(authenticatorMock).authenticateUser(username, password);\n\n\/\/ ...<\/pre>\nTo verify that authenticatorMock<\/code> mock’s authenticateUser<\/code> method, with username<\/code> and password<\/code> parameters.<\/p>\nOf course, this verification only makes sense if we make it after the call is supposed to be done.<\/p>\n
Apart from checking that the method is actually being called, this verifications are useful to check that the parameters arrive to the method call as they are supposed to arrive<\/strong>. So, for example, if you run the test with the following verification:<\/p>\nAuthenticatorApplicationTest.java<\/em><\/span><\/p>\n\/\/ ...\n\nverify(authenticatorMock).authenticateUser(username, \"not the original password\");\n\n\/\/ ...<\/pre>\nThe test will fail.<\/p>\n
6.2. Verify that method has been called n<\/em> times<\/h3>\nApart from checking that the method has been called or not, we have many possibilities regarding to number of method calls. Let’s see how we can do it:<\/p>\n
AuthenticatorApplicationTest.java<\/em><\/span><\/p>\n\/\/ ...\n\nverify(authenticatorMock, times(1)).authenticateUser(username, password);\nverify(authenticatorMock, atLeastOnce()).authenticateUser(username, password);\nverify(authenticatorMock, atLeast(1)).authenticateUser(username, password);\nverify(authenticatorMock, atMost(1)).authenticateUser(username, password);\n\n\/\/ ...<\/pre>\nAs you can see, we have different notations available to make the verifications: specifying the number of times that the mocking method should be called, how much times should be called at least, and how much at most.<\/p>\n
As in the previous example, the verifications are made for the exact parameters that the mocking method uses<\/strong>.<\/p>\nWe can also verify that the method has never been called:<\/p>\n
AuthenticatorApplicationTest.java<\/em><\/span><\/p>\n\/\/ ...\n\nverify(authenticatorMock, never()).authenticateUser(username, password); \/\/ This will make the test fail!\n\n\/\/ ...<\/pre>\nWhich, actually, is equivalent to times(0)<\/code>, but would be more expressive when we really want to verify that a method has never been called.<\/p>\n6.3. Verify method call order<\/h3>\n
We can also verify in which order have been executed the mock methods.<\/p>\n
To see how it works, let’s add a dummy method in the interface:<\/p>\n
AuthenticatorInterface.java<\/em><\/span><\/p>\n\/\/ ...\n\npublic void foo();\n\n\/\/ ...<\/pre>\nAnd also call it from the original AuthenticatorApplication.authenticate()<\/code> method:<\/p>\nAuthenticatorApplication.java<\/em><\/span><\/p>\n\/\/ ...\n\npublic boolean authenticate(String username, String password) throws EmptyCredentialsException{\n boolean authenticated;\n\n this.authenticator.foo();\n authenticated = this.authenticator.authenticateUser(username, password);\n \n return authenticated;\n}\n\n\/\/ ...<\/pre>\nNow, let’s see how we would verify that the foo()<\/code> method is called before authenticateUser()<\/code> method:<\/p>\nAuthenticatorApplicationTest.java<\/em><\/span><\/p>\n\/\/ ...\n\nInOrder inOrder = inOrder(authenticatorMock);\ninOrder.verify(authenticatorMock).foo();\ninOrder.verify(authenticatorMock).authenticateUser(username, password);\n\n\/\/ ...<\/pre>\nWe just have to create an InOrder<\/code> instance for the mock object to make the verification, and then call its verify()<\/code> method in the same order we want to make the verification. So, the following snippet, for the current AuthenticatorApplication.authenticate()<\/code> method, will make the test fail:<\/p>\nAuthenticatorApplicationTest.java<\/em><\/span><\/p>\n\/\/ ...\n\nInOrder inOrder = inOrder(authenticatorMock);\ninOrder.verify(authenticatorMock).authenticateUser(username, password); \/\/ This will make the test fail!\ninOrder.verify(authenticatorMock).foo();\n\n\/\/ ...<\/pre>\nBecause in the method the mocking object is used, authenticateUser()<\/code> is called after foo()<\/code>.<\/p>\n6.4. Verification with timeout<\/h3>\n
Mockito verification also allows to specify a timeout for the mock methods execution. So, if we want to ensure that our authenticateUser()<\/code> method runs in, for example, 100 milliseconds or less, we would do the following:<\/p>\nAuthenticatorApplicationTest.java<\/em><\/span><\/p>\n\/\/ ...\n\nverify(authenticatorMock, timeout(100)).authenticateUser(username, password);\n\n\/\/ ...<\/pre>\nThe timeout verification can be combined with the method call, so, we could verify the timeout for n<\/em> method calls:<\/p>\nAuthenticatorApplicationTest.java<\/em><\/span><\/p>\n\/\/ ...\n\nverify(authenticatorMock, timeout(100).times(1)).authenticateUser(username, password);\n\n\/\/ ...<\/pre>\nAnd any other method call verifier.<\/p>\n
7. Throwing exceptions<\/h2>\n
Mockito allows its mocks to throw exceptions. Is possible to make a mock method throw an exception that is not defined in the method signature, but is better to agree in a common method definition from the beginning, including exception throwing.<\/p>\n
We could create an exception class to be thrown when, for example, empty credentials are provided:<\/p>\n
EmptyCredentialsException.java<\/em><\/span><\/p>\npackage com.javacodegeeks.mockitotutorial.basecode;\n\npublic class EmptyCredentialsException extends Exception {\n \n public EmptyCredentialsException() {\n super(\"Empty credentials!\");\n }\n}<\/pre>\nWe add it to the method signature of our AuthenticatorInterface<\/code>, and also to its call in AuthenticatorApplication<\/code>:<\/p>\nAuthenticatorInterface.java
\n<\/em><\/span><\/p>\npackage com.javacodegeeks.mockitotutorial.basecode;\n\npublic interface AuthenticatorInterface {\n\n \/**\n * User authentication method definition.\n *\n * @param username The user name to authenticate.\n * @param password The password to authenticate the user.\n * @return True if the user has been authenticated; false if it has not.\n * @throws EmptyCredentialsException If the received credentials (user name, password) are\n * empty.\n *\/\n public boolean authenticateUser(String username, String password) throws EmptyCredentialsException;\n\n}<\/pre>\nFor the test, we will create another test case for expecting the exception:[ulp id=’GhnY46zldrhgoeym’]<\/p>\n
AuthenticatorApplicationTest.java<\/em><\/span><\/p>\n\/\/ ...\n\n@Test (expected = EmptyCredentialsException.class)\npublic void testAuthenticateEmptyCredentialsException() throws EmptyCredentialsException {\n AuthenticatorInterface authenticatorMock;\n AuthenticatorApplication authenticator;\n \n authenticatorMock = Mockito.mock(AuthenticatorInterface.class);\n authenticator = new AuthenticatorApplication(authenticatorMock);\n \n when(authenticatorMock.authenticateUser(\"\", \"\"))\n .thenThrow(new EmptyCredentialsException());\n \n authenticator.authenticate(\"\", \"\");\n}<\/pre>\nAs you can see, is almost identical to adding return values to the mock. The only difference is that we have to call thenThrow()<\/code>, passing the exception instance we want to be thrown. And, of course, we have to handle the exception; in this case, we have used the expected<\/code> rule to “assert” the exception.<\/p>\n8. Shorthand mock creation<\/h2>\n
For a few mocks, creating every mock object is not a problem. But, when there is a considerable number of them, it can be quite tedious to create every mock.<\/p>\n
Mockito provides a shorthand notation, which is really expressive, to inject the mock dependencies<\/strong>.<\/p>\nIf we want to inject dependencies with Mockito, we have to take the two things into account:<\/p>\n
\n- Only works for class scope, not for function scope.<\/li>\n
- We must run the test class with
MockitoJUnitRunner.class<\/code>.<\/li>\n<\/ul>\nSo, we would have to do the following:<\/p>\n
AuthenticatorApplicationTest.java<\/em><\/span><\/p>\n\/\/ ...\n\n@RunWith(MockitoJUnitRunner.class)\npublic class AuthenticatorApplicationTest {\n\n @Mock\n private AuthenticatorInterface authenticatorMock;\n \n @InjectMocks\n private AuthenticatorApplication authenticator;\n\n \/\/ ...\n}<\/pre>\nWith the @Mock<\/code> annotation, we define the dependencies to inject. And then, with @InjectMocks<\/code>, we specify where to inject the defined dependencies. With only those annotations, we have an instance of AuthenticatorApplication<\/code> with the AuthenticatorInterface<\/code> injected.<\/p>\nTo perform the injection, Mockito tries the following ways, in order:<\/p>\n
\n- By constructor (as we have).<\/li>\n
- By setter.<\/li>\n
- By class field.<\/li>\n<\/ol>\n
If Mockito is unable to do the injection, the result will be a null reference to the object to be injected, which in this case, would be AuthenticatorApplication<\/code>.<\/p>\nBut, as we have a constructor where the interface is passed, Mockito is supposed to do the injection properly. So now, we could make another test case to test it:<\/p>\n
AuthenticatorApplicationTest.java<\/em><\/span><\/p>\n@Test\npublic void testAuthenticateMockInjection() throws EmptyCredentialsException {\n String username = \"javacodegeeks\";\n String password = \"s4f3 p4ssw0rd\";\n\n when(this.authenticatorMock.authenticateUser(username, password))\n .thenReturn(true);\n\n boolean actual = this.authenticator.authenticate(\"javacodegeeks\", \"s4f3 p4ssw0rd\");\n \n assertTrue(actual);\n}<\/pre>\nWe don’t have to do anything more than the test itself, Mockito has created an instance for the AuthenticatorApplication<\/code> with the injected mock.<\/p>\n9. Mocking void<\/em> returning methods<\/h2>\nIn the previous examples, we have used when()<\/code> for adding behavior to the mocks. But this way won’t work for methods that return void<\/code>. If we try to use when()<\/code> with a void method, the IDE will mark an error, and it won’t let us compile the code.<\/p>\nFirst, we are going to change the previous example to make AuthenticatorInterface<\/code> method return void<\/code>, and make it throw an exception if the user has not been successfully authenticated, to give sense to the void<\/code> return. We are going to create another package com.javacodegeeks.mockitotutorial.voidmethod<\/code>, not to modify the previous working code.<\/p>\nAuthenticatorInterface.java<\/em><\/span><\/p>\npackage com.javacodegeeks.mockitotutorial.voidmethod;\n\npublic interface AuthenticatorInterface {\n\n \/**\n * User authentication method definition.\n *\n * @param username The user name to authenticate.\n * @param password The password to authenticate the user.\n * @throws NotAuthenticatedException If the user can't be authenticated.\n *\/\n public void authenticateUser(String username, String password) throws NotAuthenticatedException;\n\n}<\/pre>\nAnd also, its call:<\/p>\n
AuthenticatorApplication.java<\/em><\/span><\/p>\npackage com.javacodegeeks.mockitotutorial.voidmethod;\n\npublic class AuthenticatorApplication {\n\n private AuthenticatorInterface authenticator;\n\n \/**\n * AuthenticatorApplication constructor.\n *\n * @param authenticator Authenticator interface implementation.\n *\/\n public AuthenticatorApplication(AuthenticatorInterface authenticator) {\n this.authenticator = authenticator;\n }\n\n \/**\n * Tries to authenticate an user with the received user name and password, with the received\n * AuthenticatorInterface interface implementation in the constructor.\n *\n * @param username The user name to authenticate.\n * @param password The password to authenticate the user.\n * @throws NotAuthenticatedException If the user can't be authenticated.\n *\/\n public void authenticate(String username, String password) throws NotAuthenticatedException {\n this.authenticator.authenticateUser(username, password);\n }\n}<\/pre>\nThe required exception class also:<\/p>\n
NotAuthenticatedException.java<\/em><\/span><\/p>\npackage com.javacodegeeks.mockitotutorial.voidmethod;\n\npublic class NotAuthenticatedException extends Exception {\n \n public NotAuthenticatedException() {\n super(\"Could not authenticate!\");\n }\n}<\/pre>\nNow, to mock AuthenticatorInterface.authenticateUser<\/code>, we have to use the do<\/code> family methods:<\/p>\nAuthenticatorApplicationTest.java<\/em><\/span><\/p>\npackage com.javacodegeeks.mockitotutorial.voidmethod;\n\nimport static org.mockito.Mockito.doThrow;\n\nimport org.junit.Test;\nimport org.mockito.Mockito;\n\npublic class AuthenticatorApplicationTest {\n\n @Test(expected = NotAuthenticatedException.class)\n public void testAuthenticate() throws NotAuthenticatedException {\n AuthenticatorInterface authenticatorMock;\n AuthenticatorApplication authenticator;\n String username = \"JavaCodeGeeks\";\n String password = \"wrong password\";\n \n authenticatorMock = Mockito.mock(AuthenticatorInterface.class);\n authenticator = new AuthenticatorApplication(authenticatorMock);\n \n doThrow(new NotAuthenticatedException())\n .when(authenticatorMock)\n .authenticateUser(username, password);\n \n authenticator.authenticate(username, password);\n }\n}<\/pre>\nWe are doing the same thing as in the previous example, but using a different notation (lines 20, 21, 22). We could say that it’s almost the same syntax, but inverted: first, we add the behavior (a throw<\/code> behavior); and then, we specify the method we are adding the behavior to.<\/p>\n10. Mocking real objects: @Spy<\/h2>\n
Exists the possibility of creating mocks that wrap objects, i.e., instances of implemented classes. This is called “spying” by Mockito.<\/p>\n
When you call the method of a spied object, the real method will be called, unless a predefined behavior was defined.<\/p>\n
Let’s create a new test case in a new package to see how it works:<\/p>\n
SpyExampleTest.java<\/em><\/span><\/p>\npackage com.javacodegeeks.mockitotutorial.spy;\n\nimport static org.mockito.Mockito.*;\n\nimport java.util.HashMap;\nimport java.util.Map;\n\nimport org.junit.Test;\n\npublic class SpyExampleTest {\n\n @Test\n public void spyExampleTest() {\n Map<String, String> hashMap = new HashMap<String, String>();\n Map<String, String> hashMapSpy = spy(hashMap);\n \n System.out.println(hashMapSpy.get(\"key\")); \/\/ Will print null.\n \n hashMapSpy.put(\"key\", \"A value\");\n System.out.println(hashMapSpy.get(\"key\")); \/\/ Will print \"A value\".\n \n when(hashMapSpy.get(\"key\")).thenReturn(\"Another value\");\n System.out.println(hashMapSpy.get(\"key\")); \/\/ Will print \"Another value\".\n }\n}<\/pre>\nAs you can see, we can both delegate the method call to the real implementation, or define a behavior.<\/p>\n
You might think that this is a quite odd feature. And you’ll probably right. In fact, Mockito documentation recommends to use this only occasionally<\/strong>.<\/p>\n11. Summary<\/h2>\n
This tutorial has explained what mocking is, and how to put in practice this technique in Java with Mockito framework. We have seen how to add predefined behaviors to our mock objects, and several ways of verifying that those mock objects behave as they are supposed to do. We also have seen the possibility of mocking real objects, a feature that should be used carefully.<\/p>\n
12. Download the Eclipse Project<\/h2>\n
This was a tutorial of Mockito.<\/p>\n
Download<\/strong>
![](\"http:\/\/examples.javacodegeeks.com\/wp-content\/uploads\/2016\/05\/1-Add-JUnit-1.jpg\")
<\/p>\n![](\"http:\/\/examples.javacodegeeks.com\/wp-content\/uploads\/2016\/05\/2-Add-JUnit-2.jpg\")
<\/p>\n![](\"http:\/\/examples.javacodegeeks.com\/wp-content\/uploads\/2016\/05\/3-Add-mockito-JAR-to-buildpath.jpg\")
<\/p>\n