I am trying to mock a soap call which is returning null as response.
I have a java class where I am making a call to fedex web services to get the parsed address validated. Till here everything is fine, but when it comes to unit testing the issue arises. In test I am trying to mock the soap call by passing the same request parameters that is getting passed in actual java class but the mock is returning the response as null because of the request what I am passing is not same as what the soap call is expecting in java class.
Java class code (abc.java)-
SOAPMessage payload = getAddressRequestPayload();
SOAPMessage responseMessage = soapConnection.call(payload, settings.addressUrl());
Test code (junit4)-
SOAPMessage testResponse = getMockResponse();
SOAPMessage testPayload = abc.getAddressRequestPayload();
when(mockSoapConnection.call(testPayload, settings.addressUrl())).thenReturn(testResponse);
Also I have tried getting the string xml request payload from java class and appending the new timestamp using fakeclock in test class to match both payloads but it seems to be different. One way is give generic soapmessage class in when call like -
when(mockSoapConnection.call(any(SOAPMessage.class), anyString())).thenReturn(testResponse)
Then the test is passing, but that is not the correct way of checking a specific call.So how do I get to know the differnce between the payloads or is there any other way to mock the soap call??
Any help is appreciated.
Saurabh
If you're using any kind of matching framework like the one Mockito has, be careful to ensure that you really do have equality in the things you're setting up as expectations. If your SOAPMessage class for instance has no equals method then the mock will not work unless it gets the exact same instance of testPayload that's used in your test. If you're creating a new SOAPMessage in your class under test, and there's no equals method or the equals method would return "false", then it won't match and it won't work.
Generally if you're looking for complex functionality in a mock, it's easier to roll out your own class as a test double. Start by creating an implementation of the interface that checks for the relevant parameters and returns a response if they're present, and refactor it as you add more requirements.
It can be an inner class of the test, but since it crosses an integration / module boundary, you'll probably find that it's useful enough elsewhere to stick it in its own testHelpers folder or equivalent.