valid construction:
#InjectMocks
SomeClass sc = mock(SomeClass.class);
Invalid construction:
#InjectMocks
#Mock
SomeClass sc;
I want to inject mocks to another mock. I want to use only annotation style.
Why was in Mockito forbid second construction ?
Update
example:
public class ArrTest {
private SomeClass someClass;
public List<String> foo(){
anotherMethod(); // I suppose that this method works. I want to test it separately.
//logic which I need to test
return someClass.doSmth();// I suppose that this method works. I want to test it separately.
}
public void anotherMethod(){
///...
}
}
public class SomeClass {
public List<String> doSmth(){
return null;
}
}
test:
public class ArrTestTest {
#InjectMocks
ArrTest arrTest = Mockito.mock(ArrTest.class);
#Mock
SomeClass someClass;
#Test
public void fooTest(){
Mockito.when(someClass.doSmth()).thenReturn(new ArrayList<String>());
Mockito.doNothing().when(arrTest).anotherMethod();
System.out.println(arrTest.foo());
}
}
It sounds like you're trying to do something that doesn't really make sense. You shouldn't need to inject any dependencies into your mock since mocks by definition don't have any behaviour until you define it with when(mock.someMethod()).thenAnswer() or some variation.
(except perhaps if you're using a spy(), but you've specifically said you're using a #Mock).
Maybe you could explain your use case and why you're trying to inject dependencies into a mock?
#InjectMocks specifically indicates that the annotated field will NOT contain a mock. Annotating #InjectMocks #Mock is not just unsupported—it's contradictory.
To return stubs wherever possible, use this:
#Mock(answer=Answers.RETURNS_DEEP_STUBS)
YourClass mockYourClassWithDeepStubs;
But heed the official documentation for this Answer:
WARNING: 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).
Good quote I've seen one day on the web: every time a mock returns a mock a fairy dies.
A mock doesn't have any real implementation. #InjectMocks would try to find and call setters for whatever mock objects have already been created and pass them in. Mockito "knows" that this is kinda pointless on a mock, since there won't be any way to get the mock objects back out, much less do anything meaningful with them.
Related
I need mock some class with final method using mockito. I have wrote something like this
#Test
public void test() {
B b = mock(B.class);
doReturn("bar called").when(b).bar();
assertEquals("must be \"overrided\"", "bar called", b.bar());
//bla-bla
}
class B {
public final String bar() {
return "fail";
}
}
But it fails.
I tried some "hack" and it works.
#Test
public void hackTest() {
class NewB extends B {
public String barForTest() {
return bar();
}
}
NewB b = mock(NewB.class);
doReturn("bar called").when(b).barForTest();
assertEquals("must be \"overrided\"", "bar called", b.barForTest());
}
It works, but "smells".
So, Where is the right way?
Thanks.
From the Mockito FAQ:
What are the limitations of Mockito
Cannot mock final methods - their real behavior is executed without any exception. Mockito cannot warn you about mocking final methods so be vigilant.
There is no support for mocking final methods in Mockito.
As Jon Skeet commented you should be looking for a way to avoid the dependency on the final method. That said, there are some ways out through bytecode manipulation (e.g. with PowerMock)
A comparison between Mockito and PowerMock will explain things in detail.
You can use Powermock together with Mockito, then you do not need to subclass B.class. Just add this to the top of your test class
#RunWith(PowerMockRunner.class)
#PrepareForTest(B.class)
#PrepareForTest instructs Powermock to instrument B.class to make the final and static methods mockable. A disadvantage of this approach is that you must use PowerMockRunner which precludes use of other test runners such as the Spring test runner.
Mockito 2 now supports mocking final methods but that's an "incubating" feature. It requires some steps to activate it which are described here:
https://github.com/mockito/mockito/wiki/What's-new-in-Mockito-2#mock-the-unmockable-opt-in-mocking-of-final-classesmethods
Mockito 2.x now supports final method and final class stubbing.
From the docs:
Mocking of final classes and methods is an incubating, opt-in feature. This feature has to be explicitly activated by creating the file src/test/resources/mockito-extensions/org.mockito.plugins.MockMaker containing a single line:
mock-maker-inline
After you create this file you can do:
final class FinalClass {
final String finalMethod() { return "something"; }
}
FinalClass concrete = new FinalClass();
FinalClass mock = mock(FinalClass.class);
given(mock.finalMethod()).willReturn("not anymore");
assertThat(mock.finalMethod()).isNotEqualTo(concrete.finalMethod());
In subsequent milestones, the team will bring a programmatic way of using this feature. We will identify and provide support for all unmockable scenarios.
Assuming that B class is as below:
class B {
private String barValue;
public final String bar() {
return barValue;
}
public void final setBar(String barValue) {
this.barValue = barValue;
}
}
There is a better way to do this without using PowerMockito framework.
You can create a SPY for your class and can mock your final method.
Below is the way to do it:
#Test
public void test() {
B b = new B();
b.setBar("bar called") //This should the expected output:final_method_bar()
B spyB = Mockito.spy(b);
assertEquals("bar called", spyB.bar());
}
Mockito can be used to mock final classes or final methods. The problem is, this doesn't come as out of the box feature from Mockito and needs to be configured explicitely.
So, in order to do that,
Create a text file named org.mockito.plugins.MockMaker to the project's src/test/resources/mockito-extensions directory and add a single line of text as below
mock-maker-inline
Once done, you can use the mockito's when method to mock the behaviour like any other regular method.
See detailed examples here
I just did this same thing. My case was that I wanted to ensure the method didn't cause an error. But, since it's a catch/log/return method, I couldn't test for it directly without modifying the class.
I wanted to simply mock the logger I passed in. But, something about mocking the Log interface didn't seem to work, and mocking a class like SimpleLog didn't work because those methods are final.
I ended up creating an anonymous inner class extending SimpleLog that overrode the base-level log(level, string, error) method that the others all delegate to. Then the test is just waiting for a call with a level of 5.
In general, extending a class for behavior isn't really a bad idea, and might be preferable to mocking anyway if it's not too complicated.
I am using JDK 11 and spring boot.
I am implementing a rest API and have 3 layers:
controller
service layer
data access layer
I had classes against interfaces at the data-access-layer and did not have any interface at the service layer.
I wrote integration tests using MockMvc, Mockito, etc to exercise the whole path for each point, exposed by the controller. This was not a problem until I tried to introduce the interface at the service layer.
Initially, I mocked only repositories/Daos. So the class structure looked like:
public interface ClientRepo{
......
}
public class ClientRepoImpl implements ClientRepo{
......
}
Mocked the returned data as:
#MockBean
private ClientRepo client;
....
Mockito.when(client.isExistFkUnitId(Mockito.any(UUID.class))).thenReturn(false);
Everything was fine so far.
Now I have introduced interface at the service layer as :
public interface ClientService{
......
}
public class ClientServiceImpl implements ClientService{
......
}
And tried ( Trying to call actual service method):
#MockBean
private ClientService clientService;
....
Mockito.when(clientService.isExistFkUnitId(Mockito.any())).thenCallRealMethod();
But getting nothing but null all the time.
Is there a way to make the real method call keeping the interface?
I think you want to use #Spy annotation instead of #Mock annotation on the field where you want to call the real method. I don't happen to have an example to verify this though.
https://javadoc.io/doc/org.mockito/mockito-core/2.21.0/org/mockito/Spy.html
Then you can do doCallRealMethod().when(clientService.isExistFkUnitId(Mockito.any())).
Because with a spy object you call doReturn/when instead of when/doReturn.
https://javadoc.io/doc/org.mockito/mockito-core/2.21.0/org/mockito/Mockito.html#do_family_methods_stubs
Well, there is no "real" method to call. (Ignoring the fact that default methods in interfaces are a thing nowadays)
Generally, unit tests should be written for the target class in an isolated fashion. Like this, you are always "testing" the "isExistFkUnitId" method as well.
You could set the mock up for specific values:
Mockito.when(clientService.isExistFkUnitId("valueA").thenReturn("answerA");
Mockito.when(clientService.isExistFkUnitId("valueB").thenReturn("answerB");
Anyways... to respond to your actual question:
If possible, you can instantiate the implementation in a way that the desired method is working and call it through the mock:
ClientServiceImpl clientServiceImpl = new ClientServiceImpl(...);
// spaghetti code only for demonstration purposes ;)
Mockito.when(clientService.isExistFkUnitId(Mockito.any())).then(i -> clientServiceImpl.isExistFkUnitId((String) i.getArguments()[0]));
POC test:
#Test
public void testit() {
Myclass myclass = new Myclass();
Myinterface mock = Mockito.mock(Myinterface.class);
Mockito.when(mock.myMethod(Mockito.any())).then(i -> myclass.myMethod((String) i.getArguments()[0]));
assertThat(mock.myMethod(" works")).isEqualTo("yeehaa works");
}
public interface Myinterface {
String myMethod(String params);
}
public static class Myclass implements Myinterface {
#Override
public String myMethod(String params) {
return "yeehaa" + params;
}
}
Not exactly a beautiful solution, but if there is no way around it, it should work.
As you are mocking an interface Mockito doesn't know which implementation are you referring. The only way will be to use the Class.
I was having the same problem. My problem was due to the ClientService having dependencies that were not mocked when I set up the tests in this format. So ClientService had a mock, but if I tried clientService.productService.get() or something of that nature the dependant productService was always null. I solved this using testing reflection:
#MockBean
DependentService mockDependentService
ControllerToTest controllerToTest
#BeforeEach
public void setup() {
mockDependentService = mock(DependentService.class);
controllerToTest = mock(ControllerToTest.class);
ReflectionTestUtils.setField(controllerToTest, "dependantService", mockDependentService);
}
#Test
void test() {
//set up test and other mocks
//be sure to implement the below code that will call the real method that you are wanting to test
when(controllerToTest.methodToTest()).thenCallRealMethod();
//assertions
}
Note that "dependantService" needs to match whatever you have named the instance of the service on your controller. If that doesn't match the reflection will not find it and inject the mock for you.
This approach allows all the methods on the controller to be mocked by default, then you can specifically call out which method you want to use the real one. Then use the reflection to set any dependencies needed with the respective mock objects.
Hope this helps!
In my implementation class I have a read write lock definition as follows,
#Inject
#Named("CustomizedLock")
private ReentrantReadWriteLock rwLock;
I'm using it in a method named run() as,
rwLock.writeLock().lock();
to lock the process. But when I'm trying to test this with mockito I found ReentrantReadWriteLock is initialized. But when I'm trying to get rwLock.writeLock() it's null. Here is my test.
#Mock
private ReentrantReadWriteLock feedReadWriteLock;
#InjectMocks
private CustomModule module = mock(CustomModule.class);
/////////////////////////
#Test
public void test() {
when(module.getReadWriteLock()).thenReturn(mock(ReentrantReadWriteLock.class));
PowerMockito.doReturn(new ReentrantReadWriteLock()).when(module.getReadWriteLock());
cacheJob.run();
}
As I said rwLock.writeLock() is null but rwLock is initialized. Please explain how this happens with mockito. And what is the ideal way to do this?
You are getting mocking wrong:
#Mock
private ReentrantReadWriteLock feedReadWriteLock;
The above creates a mock that you then somehow have to get into your class under test.
But this:
#InjectMocks
private CustomModule module = mock(CustomModule.class);
is bogus. The InjectMocks annotation exists to do that "getting it into" part for you.
In other words, you should be doing something like:
#Mock
private ReentrantReadWriteLock feedReadWriteLock;
#InjectMocks
private CustomModule module = new CustomModule();
for example. In other words: you do not mock an instance of your class under test. You create a "real" instance - and then you have to "insert" the required mock objects into that real instance. There is absolutely no point in mocking the class under test. Because you want to test your code, not something that the mocking framework mocked for you.
The InjectMocks annotation tries to do that for you (using reflection and all kinds of black magic). Unfortunately when it can't do its job, it just silently fails.
In that sense, the answer is: don't just blindly use stuff. You have to fully understand each and any line of code that you write down. Thus: read this to understand the difference between these annotations.
And just for the record: please note that you also have to either use the Mockito JUnitRunner or to manually call Mockito.initMocks() in order have the annotations do their magic.
If you want to mock the class under test, you should use #Spy.
#RunWith(MockitoJUnitRunner.class)
public class CustomModuleTest {
#Mock
private ReentrantReadWriteLock feedReadWriteLock;
#Spy
#InjectMocks
private CustomModule module;
#Test
public void test() {
doReturn(feedReadWriteLock).when(module).getReadWriteLock();
cacheJob.run();
}
}
Note that the syntax is a bit different with a spy than with a mock. The spy allows your to instantiate the real object, but mock some methods as you wish.
Here, I return feedReadWriteLock, which is annoted with #Mock, this way, you may be able to change its behavior. You don't want to return a new instance like you did in your example.
Is it possible to both mock an abstract class and inject it with mocked classes using Mockito annotations. I now have the following situation:
#Mock private MockClassA mockClassA;
#Mock private MockClassB mockClassB;
#Mock(answer = Answers.CALLS_REAL_METHODS) private AbstractClassUnderTest abstractClassUnderTest;
#Before
public void init() {
MockitoAnnotations.initMocks(this);
Whitebox.setInternalState(abstractClassUnderTest, mockClassA);
Whitebox.setInternalState(abstractClassUnderTest, mockClassB);
}
I'd like to use something like #InjectMocks on AbstractClassUnderTest but it can't be used in combination with #Mock. The current situation, with Whitebox from Powermock, works but I'm curious if it's possible to solve it with just annotations. I couldn't find any solutions or examples.
(I know about the objections to test abstract classes and I'd personally rather test a concrete implementation and just use #InjectMocks.)
I am not aware of any way to go about this, for one clear reason: #InjectMocks is meant for non-mocked systems under test, and #Mock is meant for mocked collaborators, and Mockito is not designed for any class to fill both those roles in the same test.
Bear in mind that your #Mock(CALLS_REAL_METHODS) declaration is inherently dangerous: You're testing your AbstractClassUnderTest, but you are not running any constructors or initializing any fields. I don't think you can expect a test with this design to be realistic or robust, no matter what annotations can or cannot do for you. (Personally, I was previously in favor of real partial mocks of abstract classes as a "tool in the toolbox", but I'm coming around to thinking they're too far removed from reality to be useful.)
Were I in your position, I would create a small override implementation for testing:
#RunWith(JUnit4.class) public class AbstractClassTest {
/** Minimial AbstractClass implementation for testing. */
public static class SimpleConcreteClass extends AbstractClass {
public SimpleConcreteClass() { super("foo", "bar", 42); }
#Override public void abstractMethod1() {}
#Override public String abstractMethod2(int parameter) { return ""; }
}
#InjectMocks SimpleConcreteClass classUnderTest;
#Mock mockClassA;
#Mock mockClassB;
}
At this point, you have a simple and predictable AbstractClass implementation, which you can use even without a mocking framework if you just wanted to test that AbstractClass has the same API for extension that it did before. (This is an often-overlooked test for abstract classes.) You can even extract this, as it may be useful for other testing: Should you want to override the abstract behavior for a single test class, you can create an anonymous inner class with just a single method override, or you can set classUnderTest = spy(classUnderTest); to set up Mockito proxying and the behavior you want.
(Bear in mind that #InjectMocks and #Spy can't be used reliably together, as documented in this GitHub issue and the Google Code and mailing list threads to which it links.)
I found some trick with mocking field before initialization.
#InjectMocks
private AbstractClass abstractClass;
#Mock
private MockClass mockClass;
#Before
public void init() {
abstractClass= mock(AbstractClass.class, Answers.CALLS_REAL_METHODS);
MockitoAnnotations.initMocks(this);
}
Maybe it'll help someone.
I am using Mockito to test my classes. I am trying to use Deep stubbing as I didn't a way on injecting a Mock inside another mock object in Mockito.
class MyService{
#Resource
SomeHelper somehelper;
public void create()
{
//....
somehelper.invokeMeth(t);
}
}
class SomeHelper{
#Resource
private WebServiceTemplate webServiceTemplate;
public void invokeMeth(T t)
{
try{
//...
webServiceTemplate.marshalSendAndReceive(t);
}catch (final WebServiceIOException e) {
throw new MyAppException("Service not running");
}
}
}
Now I am trying to Unit test the MyService class's create() method.
I have injected a mock for SomeHelper as follows
#Mock(answer = Answers.RETURNS_DEEP_STUBS)
SomeHelper somehelper;
What I want now is when the invokeMeth() method gets called on the mocked somehelper object it calls the real method in this case.
when(somehelper.invokeMeth(isA(RequestObject.class)))
.thenCallRealMethod();
I was expecting the webServiceTemplate not be null in this case.
However I get a Nullpointer exception when the code tries to execute the line
webServiceTemplate.marshalSendAndReceive(t);
Any clue how I can get access to a deep mock object (i.e. mock within a mock - in this case webserviceTemplete mock inside somehelper mock) and then apply a when condition to throw a WebserviceIOException ?
I want this so that I can test the MyService.create() to check it behaves properly when a WebServiceIOException is thrown down the code.
Yes of course, you are mixing real objects and mocks. Plus using the thenCallRealMethod lloks like a partial mock, it feels wrong here, it's no wonder the javadoc of this method talks about that as well.
I definatelty should stress you than, design wise, having a mock that returns a mock is often a smell. More precisely you are breaking the Demeter Law, or not following the Tell, Don't Ask principle.
Any looking at your code I don't why the code would need to mock WebServiceTemplate. You want to unit test MyService, and I don't see a relationship to WebServiceTemplate. Instead you should focus on the interactions with you helper only. And unit test SomeHelper separately where you'll be able to check the interactions between SomeHelper and WebServiceTemplate.
Here's a little example of how I see the thing:
public void ensure_helper_is_used_to_invoke_a_RequestObject() {
// given a service that has an helper collaborator
... other fixture if necessary
// when
myService.behaviorToTest();
// then
verify(someHelperMock).invokeMeth(isA(RequestObject.class));
}
How those that look for your real use case ?
Hope that helps