I'm unit testing with easymock and having a result not set in the answer object. The mock object is passed to the testing subject and after processing the same reference of the mock object is returned, but it doesn't hold the result set to it.
The code should make the picture clearer
#Test
public void test() {
DomainInterface mock = EasyMock.create("mock", DomainInterface.class);
Subject subject = new Subject();
subject.setDomainInterface(mock);
final DomainInterface domain = subject.process();
assertEquals("Not the same instance", mock, domain);
final String expected = "VALID";
final String answer = domain.getAnswer();
assertEquals("Not the expected answer", expected, answer);
}
What Subject.process is doing is a couple of validations and then setting "VALID" to the answer, but the execution fails with the assertion error message
java.lang.AssertionError: Not the expected answer expected:<VALID> but was:<null>
The subject object has a private member of type DomainInterface where the mock's reference is set, why would the answer not hold till the assertion?
Thanks in advance
I've just noticed that you're asserting that the same mock is being returned. You're also never calling replay() to put the mock into replay mode - if you had, it would throw an exception as soon as Subject tried to call any methods on it.
My guess is that you're expecting the mock to remember a call to setAnswer and reply with the same result when getAnswer is called - but mocking doesn't work like that. You should probably expect a call to setAnswer("VALID"). Something like this:
public void test() {
DomainInterface mock = EasyMock.create("mock", DomainInterface.class);
// Expect that the subject will call setAnswer with an argument of "VALID"
mock.setAnswer("VALID");
EasyMock.replay();
Subject subject = new Subject();
subject.setDomainInterface(mock);
DomainInterface domain = subject.process();
assertEquals("Not the same instance", mock, domain);
// No need to assert the result of calling getAnswer - we've already asserted
// that setAnswer will be called.
}
Personally I'm becoming a fan of hand-written fakes for many tests - mocks are great for interaction testing (aka protocol testing) but in this situation it looks like a simple fake would do just as well... or possibly a mixture, which fakes out the simple bit (the property) but allows mocks for the bits which require interaction testing.
Related
I have the following method and I wrote a unit test in Java for this method. It is coveraged except from the if statement and I also need to test this part.
#InjectMocks
private ProductServiceImpl productService;
public void demoMethod(final List<UUID> productUuidList) {
if (productUuidList.isEmpty()) {
return;
}
final Map<ProductRequest, PriceOverride> requestMap = getPriceRequests(uuidList);
productService.updateByPriceList(priceRequestMap, companyUuid);
}
However, as the method execution is finalized and does not return anything when uuidList is empty, I cannot test this if block.
So:
How can I test this if block?
Should I create a new Unit Test method for testing this if block? Or should I add related assert lines to the current test method?
Update: Here is my test method:
#Test
public void testDemoMethod() {
final UUID uuid = UUID.randomUUID();
final List<Price> priceList = new ArrayList<>();
final Price price = new Price();
price.setUuid(uuid);
priceList.add(price);
productService.demoMethod(Collections.singletonList(uuid));
}
The general idea is that you don't want to test specific code, but you want to test some behaviour.
So in your case you want to verify that getPriceRequests and priceService.updateByPriceList are not called when passing in an empty List.
How exactly you do that depends on what tools you have available. The easiest way is if you already mock priceService: then just instruct your mocking liberary/framework to verify that updateByPriceList is never called.
The point of doing a return in your if condition is that the rest of the code is not executed. I.e., if this // code omitted for brevity was to be executed, the method would not fill it's purpose. Therefore, just make sure that whatever that code does, it was not done if your list is empty.
You have 3 choices:
Write a unit test with mocks. Mockito allows you to verify() whether some method was invoked.
Write a more high-level test with database. When testing Service Facade Layer this is usually a wiser choice. In this case you can obtain the resulting state of DB in your test to check whether it did what it had to.
Refactor your code to work differently
Check out Test Pyramid and How anemic architecture spoils your tests for more details.
I am new to testing with java so it confuses me a little how to write a proper unit test to a method with no parameters and return value. In general the snippet looks like the below:
public class SplitterService {
private SentenceDAO sentenceObject;
private ObjectToXML objectToXML;
private ObjectToCSV objectToCSV;
public SplitterService(int selector, String inputPath, String outputPath) {
this(inputPath);
if (selector == 1)
objectToCSV = new ObjectToCSV(outputPath, size);
if (selector == 2)
objectToXML = new ObjectToXML(outputPath);
}
public void chooseConverter() {
if (objectToCSV != null)
objectToCSV.printRecord(sentenceObject);
if (objectToXML != null)
objectToXML.marshal(sentenceObject);
}
}
There are 3 private fields in the class. There is also a constructor which instantiate a given class. Then in the chooseConverter() method a proper action is taken according to the created object.
Could you please give me some advice how to test the chooseConverter method since there is no return value and a parameter (I know Junit 5 and a little of Mockito). Im not looking for any given solution just a few words how to approach my issue.
The code, in its current form, is not unit-test friendly.
As a last resort, you can test the side effects of ObjectToCSV and ObjectToXML, but lets try to do better than that.
Ideally, the class should provide some injection points to allow you inject new mock instances of ObjectToCSV and ObjectToXML.
There are multiple ways to introduce DI like providing factories for these objects in a constructor, extracting a factory of SplitterService which injects objectToCSV or objectToXML depending on the selector.
These methods require some modifications of the client code.
extracting methods that create instances of objectToCSV and objectToXML from the constructor requires a minimal code change and is transparent to the clients. In such case, you subclass your class and override builder methods to return mocks.
if no modifications to existing code are allowed, I can recommend pulling in Powermock and mocking the constructors. Note: you must be running junit4 vintage engine, as Powermock hasnt been ported to jUnit5 yet.
https://dzone.com/articles/using-powermock-mock
you are looking at a few things here... first check that objectToCSV::printRecord (objectToCSV will be a Mockito mock) is getting called under the condition objectToCSV != null (and objectToXML:: marshal is getting called under objectToXML != null). And also you are looking for ArgumentCaptor most probably, that is to test that objectToCSV::printRecord and objectToXML.marshal is actually getting called with sentenceObject that you set.
While mocking a method, which have complex type, returning null in java
public void sendRequest(OnlineRequest request) {
OnlineResponse response = client.handleRequest(request);
System.out.println( response);
}
Mockito.when(client.handleRequest(request)).thenReturn(new OnlineResponse());
If I understand correctly, your issue is that System.out.println(response); prints null?
This is most likely due to the fact that client.handleRequest() is not being called with the request you expect. This may be an error somewhere in code you haven't provided us, OR it may simply be due to the fact that OnlineRequest does not have an implementation of equals/hash-code, so when() is never triggered because it is not called with the exact same instance of OnlineRequest as you use in your unit tests.
You might wish to test that handleRequest is called with exactly the object you expect. This can be accomplished using verify():
verify(client).handleRequest(request);
in your unit test. This too is dependent on the equals/hash-code implementation to determine whether request is the expected parameter or not.
I am new to JUnit mockito, I have this test function written for my Spring rest resource.
#Test
public void getAllMessageHappyTest() throws Exception {
List<Message> messageList = new ArrayList<>();
messageList.add(new Message(1,"Hello"));
messageList.add(new Message(5,"Hello world"));
messageList.add(new Message(3,"Hello World, G!"));
when(messageService.getAllMessages()).thenReturn(messageList);
RequestBuilder requestBuilder = MockMvcRequestBuilders.get("/messages/").accept(MediaType.APPLICATION_JSON);
MvcResult mvcResult = mockMvc.perform(requestBuilder).andReturn();
String expected = ""; // expected
JSONAssert.assertEquals(expected,mvcResult.toString(),false);
}
In the above scenario, I have the when(messageService.getAllMessages()).thenReturn(messageList); returning the messageList which is written by me(or by member of team) and I am comparing the returned JSON with the String expected which will also be written by me(or by the same member of team). So both the things are written by the same guy, so what is the point of having such kind of tests.
If I understand the question correctly the concern is this; because the person who writes the test also hardcodes (in the form of a JSON string) the expectation the test may be redundant or at least may be of limited value. Perhaps the sub text to your question is that since whoever wrote the underlying endpoint will provide the expectation then it must pass and if its success is preordained then it is of little value.
However, regardless of who writes the test and who writes the code-under-test, the example test you showed above has value because:
It tests more than the retuned JSON, it also tests ...
That the REST endpoint mapping is correct i.e. that it exposes an endpoint named "/messages/" which accepts JSON
The REST layer is using a serialiser which produces some JSON
Continued running of this test case will ensure that the expected behaviour of this endpoint continues to be met even after you (or some other member of your team) are no longer working on this code or, in other words; it acts as a regression safety net.
The code-under-test may be changed in future, if so then this test case provides a baseline against which future development can take place.
The test case provides a form of documentation for your code; people who are unfamiliar with this codebase can review the tests to understand how the code is expected to behave.
In addition, this test case could be extended to include tests for sad paths such as invalid repsonses, unsecured access attempts etc thereby improving test coverage.
Update 1: in response ot this comment:
even if someone makes changes in an actual code and now after making actual code is producing a different kind of JSON(say not as required) even then too test case will pass because when then is hardcoded and expected is also hardcoded. So what is the point?
A test like this clearly makes no sense:
String json = "...";
when(foo.getJson()).thenReturn(json);
assertEquals(json, foo.getJson());
Bu that is not what your test does. Instead your test asserts that the response - in the form of JSON - matches the serialised form of the response returned by your mocked messageService.getAllMessages(). So, your test covers the serialisation piece along with the various aspects of the Spring MVC layer such as the endpoint->controller mapping and interceptors and filters (if you have any).
I want to use mockito spy.
When I set a return value in both following ways:
when(imagesSorterSpy.sortImages(imagesAsInsertionOrder, user)).thenReturn(imagesSorterSpy.sortImages(imagesAsInsertionOrder, user, fakeNowDate));
doReturn(imagesSorterSpy.sortImages(imagesAsInsertionOrder, user, fakeNowDate)).when(imagesSorterSpy).sortImages(imagesAsInsertionOrder, user);
I see the return value is being evaluated eagerly
meaning when this "setting" line is executed.
how can i force the spy to evaluate the return value only on demand?
meaning when the "when" condition is met.
update
Thanks to #RobbyCornelissen I have tried this code:
when(imagesSorterSpy.sortImages(imagesAsInsertionOrder, user)).thenAnswer(new Answer() {
public Object answer(InvocationOnMock invocation) {
Object[] args = invocation.getArguments();
ImagesSorter mock = (ImagesSorter)invocation.getMock();
return mock.sortImages((List<Image>)args[0], (UserInfo)args[1], fakeNowDate);
}
});
But it didn't help:
1) the "when" expression was invoked immediately. (not wanted)
2) eventually the callback wasn't call.
First let me warn you on partial mocks, because that is what the code is actually doing, it's wrong design wise. It may be more relevant to use a strategy pattern to compose behavior of the tested subject. Mockito team (including me) strongly advises to stay away of partial mocks whenever possible.
EDIT : I don't know the code and I don't know exactly which component under test but from what I gather there's a type responsible to sort images, let's call it ImagesSorter.
So first case ImagesSorter is a dependency of a test subject, so in this case just stubbing the mock of ImagesSorter will do.
If however it is ImagesSorter itself under test, and stubbing a special method of this class is called a partial mock and it is plain wrong. It exposes internal of the production code in the test. So there's several solutions.
As the code snippet showed in the answer shows a fakeDate, one of the solution is to not use things like new Date() and code a simple class TimeSource whose sole responsibility is to provide a date. And in tests the bwhavior of this TimeSOurce could be overriden.
A simplier solution would be to use JodaTime as it provides this functionality built in.
If the scope of test goes beyond changing the date, then maybe ImagesSorter needs a way to be configured with other objects. Inspiration on how to do it can be found with the cache builder of guava. If the configuration is dead simple then a simple constructor coud do it.
That could look like :
class ImagesSorter {
ImagesSorterAlso algo;
ImagesSorter(ImagesSorterAlgo algo) { this.algo = algo; }
Iterable sortImages(...) {
algo.sort(...);
}
}
interface ImagesSorterAlgo {
Iterable sort(...);
}
Now about your questions :
1) the "when" expression was invoked immediately. (not wanted)
It is expected imagesSorterSpy is a spy so by default it calls the real code. Instead you should use the alternate API, the same that #RobbyCornelissen showed. i.e.
doAnswer(sortWithFakeDate()).when(imagesSorterSpy).sortImages(imagesAsInsertionOrder, user);
// with BDD aliases (BDDMockito) which I personnaly finds better
willAnswer(sortWithFakeDate()).given(imagesSorterSpy).sortImages(imagesAsInsertionOrder, user);
will(sortWithFakeDate()).given(imagesSorterSpy).sortImages(imagesAsInsertionOrder, user);
sortWithFakeDate() would a static factory method that returns the answer, so the code reads well, and maybe reused elsewhere.
2) eventually the callback wasn't call.
This issue is most probably due to non equal arguments. You may need to check the equals method. Or relax the stub using the any() matcher.
I don't know the types of the arguments and classes you're using, so I can't provide a complete example, but you can stub using callbacks with the Answer<T> interface:
Mockito.doAnswer(new Answer() {
Object answer(InvocationOnMock invocation) {
ImagesSorter mock = (ImagesSorter) invocation.getMock();
Object[] args = invocation.getArguments();
return mock.sortImages((List<Image>) args[0], (UserInfo) args[1],
fakeNowDate);
}
}).when(imagesSorterSpy).sortImages(imagesAsInsertionOrder, user);