I am experimenting with converting some of my unit tests from using JMock to using Mockito and have hit a few stumbling blocks.
Firstly in my tests when using JMock the verification and returning of the stub happen in one step as follows
contextMockery.checking(new Expectations() {{
oneOf(dateUtilityService).isBeforeToday(URGENT_DATE);
will(returnValue(true));
}});
This essentially verifies that the method is being called and returns a canned value at the same time. The test fails if isBeforeToday method is NOT called and returns my canned value of true at the same time. Whereas when using Mockito I have to verify that the method is being called and then return my canned value in separate steps which are pretty much a duplicate as follows:
doReturn(true).when(dateUtilityService).isBeforeToday(URGENT_DATE);
verify(dateUtilityService).isBeforeToday(URGENT_DATE);
Is there no way to do this in one step?
Secondly, if I forget to list a method call to one of my mocks in my expectations, JMock fails the test with "Unexpected invocation exception" which in my opinion is correct whereas Mockito will happily pass the test unless I explicitly verify that a method call to the mock must never happen, is this correct (seems wrong)? Is there a way to tell mockito to fail the test if unexpected method calls are made to my mocked out dependencies?
1.
When you stub a method call the verify method is usually not necessary - you should check the action based on the return value (in your case something might happen or something will be returned when the dateUtilityService returns true - check that instead of verifying interaction with a mock.
Mockito documentation also talks about this. http://site.mockito.org/mockito/docs/current/org/mockito/Mockito.html#2
2.
This actually leads to fragile tests and is not recommended way of doing things with mockito. That's why there is no way to set this behaviour.
See http://site.mockito.org/mockito/docs/current/org/mockito/Mockito.html#8
Related
In Mockito documentation and javadocs it says
It is recommended to use ArgumentCaptor with verification but not with stubbing.
but I don't understand how ArgumentCaptor can be used for stubbing. Can someone explain the above statement and show how ArgumentCaptor can be used for stubbing or provide a link that shows how it can be done?
Assuming the following method to test:
public boolean doSomething(SomeClass arg);
Mockito documentation says that you should not use captor in this way:
when(someObject.doSomething(argumentCaptor.capture())).thenReturn(true);
assertThat(argumentCaptor.getValue(), equalTo(expected));
Because you can just use matcher during stubbing:
when(someObject.doSomething(eq(expected))).thenReturn(true);
But verification is a different story. If your test needs to ensure that this method was called with a specific argument, use ArgumentCaptor and this is the case for which it is designed:
ArgumentCaptor<SomeClass> argumentCaptor = ArgumentCaptor.forClass(SomeClass.class);
verify(someObject).doSomething(argumentCaptor.capture());
assertThat(argumentCaptor.getValue(), equalTo(expected));
Hypothetically, if search landed you on this question then you probably want this:
doReturn(someReturn).when(someObject).doSomething(argThat(argument -> argument.getName().equals("Bob")));
Why? Because like me you value time and you are not going to implement .equals just for the sake of the single test scenario.
And 99 % of tests fall apart with null returned from Mock and in a reasonable design you would avoid return null at all costs, use Optional or move to Kotlin. This implies that verify does not need to be used that often and ArgumentCaptors are just too tedious to write.
The line
when(someObject.doSomething(argumentCaptor.capture())).thenReturn(true);
would do the same as
when(someObject.doSomething(Matchers.any())).thenReturn(true);
So, using argumentCaptor.capture() when stubbing has no added value. Using Matchers.any() shows better what really happens and therefor is better for readability.
With argumentCaptor.capture(), you can't read what arguments are really matched.
And instead of using any(), you can use more specific matchers when you have more information (class of the expected argument), to improve your test.
And another problem:
If using argumentCaptor.capture() when stubbing it becomes unclear how many values you should expect to be captured after verification. We want to capture a value during verification, not during stubbing because at that point there is no value to capture yet. So what does the argument captors capture method capture during stubbing? It capture anything because there is nothing to be captured yet.
I consider it to be undefined behavior and I don't want to use undefined behavior.
I'm working on unit testing a method in Mockito and mockito keeps sending an empty zero size list even when I have initialized the list that is to be returned.
This is the code to be tested. Note that nonCashIncludedPaymentPlanActive is always true ( Mocked ).
List<DebtAccountTransaction> debtAccountTransactionList = null;
boolean nonCashIncludedPaymentPlanActive = balancingPlanService.checkNonCashIncludedPaymentPlanParameter(debtAccountId);
if (nonCashIncludedPaymentPlanActive) {
debtAccountTransactionList = debtAccountTransactionDao
.getDebtAccountTransactionListByDebtAccountIdListWithCN(baseDebtIdAccountList, null);
}
if (debtAccountTransactionList.isEmpty()) {
throw new SfcException("DISPLAY.PAYMENT_PLAN_WITH_NO_BALANCE_SERVICE_FILE_CLOSED");
}
This the statement that keeps returning a List that I have mocked in mockito and added an item to it and here it returns an emptylist.
debtAccountTransactionList = debtAccountTransactionDao
.getDebtAccountTransactionListByDebtAccountIdListWithCN(baseDebtIdAccountList, null);
which then ofcourse gets caught by this line
if (debtAccountTransactionList.isEmpty()) {
throw new SfcException("DISPLAY.PAYMENT_PLAN_WITH_NO_BALANCE_SERVICE_FILE_CLOSED");
}
Thus inorder to avoid this path of execution I have done the following in Mockito:
when(debtAccountTransactionDao.getDebtAccountTransactionListByDebtAccountIdListWithCN(baseDebtIdAccountList, null)).thenReturn(
debtAccountTransactionList);
and declaration of debtAccountTransactionList is :
DebtAccountTransaction debtAccountTransaction = spy(DebtAccountTransaction.class);
debtAccountTransaction.setId(2L);
List<DebtAccountTransaction> debtAccountTransactionList = new ArrayList<DebtAccountTransaction>();
debtAccountTransactionList.add(debtAccountTransaction);
I tried mocking a List, tried different argument captors but nothing seems to work. When I debug it, Mockito does fill up the debtAccountTransactionList but with an empty List, thus it fails.
Any help with how I can make sure that Mockito sends a Non-Empty Non-Zero List so that it can bypass the isEmpty() check.
A good rule of thumb in writing tests, especially with a mocking library like Mockito: Don't confuse stubbing with verification. Stubbing (when) is about getting your system under test (SUT) into the desired state, not about asserting anything about how the SUT behaves.
In Mockito, the way to make assertions about how the SUT behaves is after the SUT runs, using verify calls. If you don't have any verify calls, you're not actually asserting anything, and your SUT can misbehave without your test catching it, which is obviously a bad thing.
As a result, it's usually best to make your matchers for stubbing (when) as broad as possible, since the goal of stubbing is just to make sure you fall into the right test case. For example, you can and often should use matchers like any() in your when() call. If you did that, you would sidestep the issue you're having here.
If you want to make assertions about the values that the SUT actually used as arguments, do that with verify, or possibly by capturing the value and making additional assertions about it directly.
The problem is the mock creation/behavior registration. This doesn't match what you put into the method and hence returns to the default behavior of returning an empty list.
as pointed out by M. Deinum
Thus there was a problem in acceptance of the argument by Mockito and it would ignore my stubbing and then return an empty list by default.
I fixed it by making sure the object that is baseDebtIdAccountList passed to the function when(debtAccountTransactionDao.getDebtAccountTransactionListByDebtAccountIdListWithCN(baseDebtIdAccountList, null)).thenReturn(
debtAccountTransactionList) is exactly the same in the rest of the code. Thus there was a mismatch in the arguments and Mockito used the default way of using an empty list.
Did you put in any place of the code something like:
debtAccountTransactionDao = Mockito.mock(NameOfTheClassOfThisDebtAccountObject.class);
?
You should put something like this before calling the method getDebtAccountTransactionListByDebtAccountIdListWithCN, so it knows it should use the mocked behavior, not the normal behavior of the method (that could be return an empty list).
Java 8, TestNg 6.8.1, Mockito 1.10.19.
This is my first experience with Mockito. I stub two methods in a class, both of them take a String and a double as parameters and return double. I only care about the second parameter in this case.
When the stubbed methods are called during the execution of my unit test stubbing works fine only once. The subsequent calls to the stubbed methods return 0 instead of increasing/decreasing the parameter. I interpret this as if the methods are not longer stubbed.
Here is the code
MyManager myManagerMock = mock(MyManager.class);
when(myManagerMock.method1(someString, someDouble)).thenReturn(someDouble + 0.5d);
when(myManagerMock.method2(someString, someDouble)).thenReturn(someDouble - 0.5d);
// the class ClassBeingTested has a private member of the type MyManager
ClassBeingTested classBeingTested = new ClassBeingTested(myManager);
// the method getSomeDoubleValue() will perform several calls myManagerMock.method1 and myManagerMock.method2
assertThat(classBeingTested.getSomeDoubleValue(someString, someDouble), is(anExpectedDoubleValue));
Here is how method 1 and method2 are called inside ClassBeingTested:
method2(someString, method1(someString, someDouble));
I wonder what I am doing wrong. As far as I understand stubbed methods can be called repeatedly and they are supposed to repeatedly return the value supplied in the "thenReturn()" method.
Thanks in advance to all who can help..
The key necessary to solve the puzzle (I missed this in the original version of the question, which I have now edited following a suggestion of a fellow forum member) was the way I called the stubbed methods inside classBeingTested.getSomeDoubleValue(someString, someDouble). This is how the calls in question look like method2(someString, method1(someString, someDouble)); . You probably can see my mistake right away.
method1 received the value someDouble, while method2 received someDouble - 0.5d returned by the method1. This is the reason why Mockito did not recognize the stubbing of method2 and the method returned 0.0d.
I had to rewrite my original "mocking"
when(myManagerMock.method1(someString, someDouble)).thenReturn(someDouble + 0.5d);
when(myManagerMock.method2(someString, someDouble)).thenReturn(someDouble - 0.5d);
and make it look this way so that the actual parameter values do not matter anymore
when(myManagerMock.method1(anyString(), anyDouble())).thenReturn(11.5d);
when(myManagerMock.method2(anyString(), anyDouble())).thenReturn(10.5d);
After that everything worked fine. I also had to abandon my "smart" processing in the "thenReturn" method.
You will have to modify the thenReturn part to return multiple values. Something like -
.thenReturn(someDouble + 0.5d, someDouble + 0.5d,..);
Mokito expects us to provide the return values as many times the stubbed method is called during test case execution. Try this and it should work fine.
This code from the documentation is totally baffling me:
List list = new LinkedList();
List spy = spy(list);
when(spy.size()).thenReturn(100); // <--- how does this spy know
// not to call the real method????
//using the spy calls *real* methods
spy.add("one");
spy.add("two");
I get it, Mockito is weird and hardly still in Java. Confusing thing is spy.* has to evaluate fully before it knows whether it's wrapped in a when() or something. How on earth would the first spy.* method not call on the real object but the later ones doe?
According to the documentation the first when(spy.size()).thenReturn(100) will actually invoke the real List.size() method, see: http://mockito.github.io/mockito/docs/current/org/mockito/Mockito.html#13
Each subsequent call of course will then return the mocked result.
If you don't want the real method to be called (e.g. when(spy.get(0)).thenReturn(...) would probably throw an IndexOutOfBoundsException, you have to use this pattern: doReturn(...).when(spy).get(0);
I don't know the exact implementation, but I can take a guess.
The call to spy(...) first proxies the given object and keeps it as a reference to delegate calls.
The call
when(spy.size()).thenReturn(100);
is practically equivalent to
Integer result = spy.size();
OngoingStubbing<Integer> stubbing = when(result); // result is useless
stubbing.thenReturn(100);
The first call to size() is invoked on the proxy. Internally, it can register the call, pushing it, for example, on a static (global) Mockito stack. When you then invoke when(), Mockito pops from the stack, recognizes the call to size() as needing stubbing and performs whatever logic required to do so.
This can explain why stubbing in a multithreaded environment is bad business.
I have two custom ArgumentMatchers and I'd like my mock to return a different value based on the argument value.
Example:
when(myMock.method(new ArgMatcher1()).thenReturn(false);
when(myMock.method(new ArgMatcher2()).thenReturn(true);
Unfortunately, the second call to when() results in an exception. This makes sense to me because, if the argument matches both ArgumentMatchers, Mockito wouldn't know whether to return true or false. Is there a way to do this in Mockito? It could even be something like:
when(myMock.method(new ArgMatcher2()).thenReturn(false).elseReturn(true);
I'm not sure how your matchers are coded, but having two different matchers is supported of course, maybe the method you are stubbing is not mockable via Mockito (final).
Also for the record it is possible to tell the stub to return different return values in different ways :
when(myMock.method(new ArgMatcher2()).thenReturn(false, false, true).thenReturn(true);
If you're interested in returning a default value from Mockito, then this I have achieved like that:
when(myMock.myMethod(any())).thenReturn(true);
when(myMosk.myMethod("some other argumetn")).thenReturn(true);
Will it help you? Hard to say, I haven't used matchers the way you do with new keyword. It might be, that Mockito doesn't understand that well your custom matchers.
Switch to syntax:
doAnswer(args->false).when(myMock).myMethod(any());