I want to test an "Adapter" object that when it receives an xml message,
it digest it to a Message object, puts message ID + CorrelationID both
with timestamps and forwards it to a Client object.=20
A message can be correlated to a previous one (e.g. m2.correlationID =3D
m1.ID).
I mock the Client, and check that Adapter successfully calls
"client.forwardMessage(m)" twice with first message with null
correlationID, and a second with a not-null correlationID.
However, I would like to precisely test that the correlationIDs are set
correctly, by grabing the IDs (e.g. m1.ID).
But I couldn't find anyway to do so.
There is a jira about adding the feature, but no one commented and it
is unassigned.
Is this really unimplemented?
I read about the alternative of redesigning the Adapter to use an
IdGenerator object, which I can stub, but I think there will be too many
objects.=20
Don't you think it adds unnecessary complexity to split objects to a so
fine granularity?
Thanks, and I appreciate any comments :-)
Tayeb
You could use a matcher (http://code.google.com/p/hamcrest) to check whether you get the correct arguments passed into your method. Note you'll need to statically import your matcher (HasCorrelationId in my example).
The example below asserts that client.forwardMessage(m) is called once with a message with null correlationId and once with a message with correlationId="abc".
import org.hamcrest.Description;
import org.hamcrest.TypeSafeMatcher;
public class HasCorrelationId extends TypeSafeMatcher<Message> {
private final Object expectedCorrelationId;
public HasCorrelationId(Object expectedCorrelationId) {
this.expectedCorrelationId = expectedCorrelationId;
}
#Override
public boolean matchesSafely(Message message) {
if (expectedCorrelationId==message.getCorrelationId()) return true;
return expectedCorrelationId==null? false: expectedCorrelationId.equals(message.getCorrelationId());
}
public void describeTo(Description description) {
description.appendText("hasCorrelationId("+expectedCorrelationId+")");
}
public static HasCorrelationId hasCorrelationId(Object correlationId) {
return new HasCorrelationId(correlationId);
}
}
... and now for the test:
public class MyTest {
private Mockery context = new Mockery();
#Test
public void testCorrelationId() {
final Client client = context.mock(Client.class);
final Message message1 = context.mock(Message.class,"message1");
final Message message2 = context.mock(Message.class,"message2");
context.checking(new Expectations(){{
allowing(message1).getCorrelationId();will(returnValue(null));
allowing(message2).getCorrelationId();will(returnValue("abc"));
one(client).forwardMessage(with(hasCorrelationId(null)));
one(client).forwardMessage(with(hasCorrelationId("abc")));
}});
client.forwardMessage(message1);
client.forwardMessage(message2);
}
}
We've made some effort to simplify writing matchers in Hamcrest 1.2. There's a new FeatureMatcher which requires less work.
Related
Here is my test method where It should be success if showLoading() and loadDataSuccess(response) was called:
#RunWith(PowerMockRunner.class)
public class PresenterTest {
#Mock
private ProfileContract.View view;
#Mock
private ProfileContract.Handler handler;
#Test
public void onLoadDataClicked() {
presenter.loadData();
verify(mView, times(1)).showLoading();
verify(mHandler, times(1)).loadDataSuccess();
}
}
UPDATE 1
Here is my presenter:
class ProfilePresenter(private val mView: ProfileContract.View) : ProfileContract.Handler {
override fun loadData() {
mView.showLoading()
mUserService.user()
.compose(RxUtil.mapper())
.subscribe({ response ->
loadDataSuccess()
}, { error ->
//stuff
})
}
}
Thanks!
If you use return statment, your test finish with success status.
I think there is a basic problem with your test setup:
You do not use verify to check if one function calles another function within the same class. Verify is used to verify that the tested class calls function on other (mocked) classes. If I am not mistaken, your setup should actually give you an error message saying that you can not use verify on instantiated classes.
What you should do -if you want to check if onCompleteClicked() produces the correct results- is to check if the data that gets changed inside the onStuffComplete() function is set correctly. You can use an assert for that.
As an example, lets say onStuffCompleted() sets completeCounter to 1
#Test
public void onCompleteClicked() {
presenter.onStuffCompleteClicked();
assertEquals(completCounter , 1);
}
And to answer your original question: verify (and assert) will pass if the requirements were met (and by this the whole test will pass) and fail if not. You do not need to add any additional stuff (but once again: verify will only work with mocked classes).
I am assigned to add unit test code coverage to a 15 years old legacy project which is not using IoC and 0 unit test. I am not allowed to refactor the code since it works perfect fine on production, management does not want other teams get involved for refactoring such as QA testing, etc.
Service class has a performService method has following code
public void performService(requestMessage, responseMessage) {
UserAccount userAccount = requestMessage.getUserAccount();
GroupAccount groupAccount = requestMessage.getGroupAccount();
Type type = requestMessage.getType();
StaticServiceCall.enroll(userAccount, groupAccount, type);
response.setStatus(Status.SUCCESS);
}
This StaticServiceCall.enroll method is calling remote service. My unit test is
#RunWith(PowerMockRunner.class)
#PrepareForTest(StaticServiceCall.class)
public class EnrollmentServiceTest {
#Test
public void testPerformService() {
mockStatic(StaticServiceCall.class);
doNothing().when(StaticServiceCall.enroll(any(UserAccount.class), any(GroupAccount.class), any(Type.class)));
service.performService(requestMessage, responseMessage);
assertEquals("Enrollment should be success, but not", Status.SUCCESS, response.getStatus);
}
Eclipse complains with The method when(T) in the type Stubber is not applicable for the arguments (void)
Eclipse stops complain if test code change to
mockStatic(StaticServiceCall.class);
doNothing().when(StaticServiceCall.class);
StaticServiceCall.enroll(any(UserAccount.class), any(GroupAccount.class), any(Type.class));
service.performService(requestMessage, responseMessage);
assertEquals("Enrollment should be success, but not", Status.SUCCESS, response.getStatus);
Test case failed with UnfinishedStubbingException. I am using powermock 1.6.6
There is a misconception on your end. You think that you need to say that doNothing() should do nothing.
That is not necessary! As these lines
#PrepareForTest(StaticServiceCall.class) ... and
mockStatic(StaticServiceCall.class);
are sufficient already.
You want to prevent the "real" content of that static method to run when the method is invoked during your test. And that is what mockStatic() is doing.
In other words: as soon as you use mockStatic() the complete implementation of the real class is wiped. You only need to use when/then/doReturn/doThrow in case you want to happen something else than nothing.
Meaning: just remove that whole doNothing() line!
#GhostCat - Thank you for your answer, it solved problem, my misconception is coming from this test case
#Test
public void testEnrollmentServiceSuccess() {
RequestMessage requestMessage = new RequestMessage();
requestMessage.setName("ENROLL");
ResponseMessage responseMessage = new ResponseMessage();
EnrollmentService mockService = mock(EnrollmentService.class);
mockService.performService(any(RequestMessage.class), any(ResponseMessage.class));
mockStatic(ClientManager.class);
when(ClientManager.isAuthenticated()).thenReturn(true);
ServiceImpl service = new ServiceImpl();
service.performService(requestMessage, responseMessage);
verify(mockService).performService(any(RequestMessage.class), any(ResponseMessage.class));
}
Here is the code snippet of ServiceImpl class based name of the request message calling different service class
public void performService(RequestMessage request, ResponseMessage response) {
try {
if (request == null) {
throw new InvalidRequestFormatException("null message");
}
if (!ClientManager.isAuthenticated()) {
throw new ServiceFailureException("not authenticated");
}
// main switch for known services
if ("ENROLL".equals(request.getName())) {
service = new EnrollmentService();
service.performService(request, response);
} else if ("VALIDATE".equals(request.getName())) {
...
Although the test passed,real implementation in EnrollmentService got called and exceptions thrown due to barebone RequestMessage object, then I googled out doNothing, thanks again for your clarification
I'm writing a unit test for a REST Service connector which is using a third party tool called Httpful.
Because I do not want to send real requests to the server, I mocked the "send" method from Httpful\Request:
$mockedRequest = $this->getMock('Httpful\Request', array('send'), array(), '', false);
$mockedRequest->expects($this->once())->method('send');
This works fine, but the Request Class has a method called expects itself, which I use in my actual code to define the acceptable mime type of the response.
$this
->getRequest('GET')
->uri(ENDPOINT . $configurationId) //by default this returns a Request Object (now mocked request)
->expects('application/json') //crashes ...
->send();
When the code gets executed, I get the following error (which is understandable):
Argument 1 passed to Mock_Request_938fb981::expects() must implement interface PHPUnit_Framework_MockObject_Matcher_Invocation, string given
Is there something like a configurable prefix for methods coming from the Mock Class like "expects"?
I don't think that you will be able to do that using the PHPUnit_MockObject class. But you can code your own and use that instead.
class MockRequest extends \Httpful\Request {
public $isSendCalled = false;
public $isUriCalled = false;
public $isExpectsCalled = false;
public function uri($url) {
if($url !== '<expected uri>') {
throw new PHPUnit_Framework_AssertionFailedError($url . " is not correct");
}
$this->isUriCalled = true;
return $this;
}
public function expects($type) {
if($type !== 'application/json') {
throw new PHPUnit_Framework_AssertionFailedError($type . " is not correct");
}
$this->isExpectsCalled = true;
return $this;
}
public function send() {
$this->isSendCalled = true;
}
}
Your line for creating the mock then just becomes:
$mockedRequest = new MockRequest();
If the constructor fo
Then in your test you can verify that the methods are called with
$this->assertTrue($mockedRequest->isSendCalled);
$this->assertTrue($mockedRequest->isUriCalled);
$this->assertTrue($mockedRequest->isExpectsCalled);
This isn't a very dynamic mock but it will pass the type hinting and does your check for you. I would create this mock in the same file as your test (though be careful about not accidentally redefining this class elsewhere in your test suite). But it gets you around the problem of having expects being overridden.
The PHPUnit_Framework_MockObject_MockObject is an interface that sets the signature for expects() also which your class wouldn't meet and so there would be an error if you were able to rename the method.
https://github.com/sebastianbergmann/phpunit-mock-objects/blob/master/src/Framework/MockObject/MockObject.php
I am using Moq in my unit test project. Most unit test examples I've seen online end with someMock.VerifyAll(); I wonder if it is OK to assert after VerifyAll(). So for example,
//Arrange
var student = new Student{Id = 0, Name="John Doe", IsRegistered = false};
var studentRepository = new Mock<IStudentRepository>();
var studentService= new StudentService(studentRepository.Object);
//Act
studentService.Register(student); //<-- student.IsRegistered = true now.
//Verify and assert
studentRepository.VerifyAll();
Assert.IsTrue(student.IsRegistered);
Any thought? Thank you.
No you should not use both together in most cases(there are always exceptions). The reason for that is you should be testing only one thing in your test for maintainability, readability and few other reasons. So it should be either Verify(VerifyAll) or Assert in your test and you name your tests accordingly.
Look at Roy Osherove's article about it:
http://osherove.com/blog/2005/4/3/a-unit-test-should-test-only-one-thing.html
VerifyAll is used to make sure certain methods are called and how many times. You use mocks for that.
Assert is used for verifying the result returned from the method you are testing. You use Stubs for that.
Martin fowler has a great article explaining the difference between mocks and stubs. If you understand it you will know the difference better.
http://martinfowler.com/articles/mocksArentStubs.html
UPDATE: example of mock vs stub using Moq as requested in the comment below. I have used Verify but you can use VerifyAll as well.
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Moq;
...
[TestClass]
public class UnitTest1
{
/// <summary>
/// Test using Mock to Verify that GetNameWithPrefix method calls
/// Repository GetName method once when Id is greater than Zero
/// </summary>
[TestMethod]
public void GetNameWithPrefix_IdIsTwelve_GetNameCalledOnce()
{
// Arrange
var mockEntityRepository = new Mock<IEntityRepository>();
mockEntityRepository.Setup(m => m.GetName(It.IsAny<int>()));
var entity = new EntityClass(mockEntityRepository.Object);
// Act
var name = entity.GetNameWithPrefix(12);
// Assert
mockEntityRepository.Verify(
m => m.GetName(It.IsAny<int>()), Times.Once);
}
/// <summary>
/// Test using Mock to Verify that GetNameWithPrefix method
/// doesn't calls Repository GetName method when Id is Zero
/// </summary>
[TestMethod]
public void GetNameWithPrefix_IdIsZero_GetNameNeverCalled()
{
// Arrange
var mockEntityRepository = new Mock<IEntityRepository>();
mockEntityRepository.Setup(m => m.GetName(It.IsAny<int>()));
var entity = new EntityClass(mockEntityRepository.Object);
// Act
var name = entity.GetNameWithPrefix(0);
// Assert
mockEntityRepository.Verify(
m => m.GetName(It.IsAny<int>()), Times.Never);
}
/// <summary>
/// Test using Stub to Verify that GetNameWithPrefix method
/// returns Name with a Prefix
/// </summary>
[TestMethod]
public void GetNameWithPrefix_IdIsTwelve_ReturnsNameWithPrefix()
{
// Arrange
var stubEntityRepository = new Mock<IEntityRepository>();
stubEntityRepository.Setup(m => m.GetName(It.IsAny<int>()))
.Returns("Stub");
const string EXPECTED_NAME_WITH_PREFIX = "Mr. Stub";
var entity = new EntityClass(stubEntityRepository.Object);
// Act
var name = entity.GetNameWithPrefix(12);
// Assert
Assert.AreEqual(EXPECTED_NAME_WITH_PREFIX, name);
}
}
public class EntityClass
{
private IEntityRepository _entityRepository;
public EntityClass(IEntityRepository entityRepository)
{
this._entityRepository = entityRepository;
}
public string Name { get; set; }
public string GetNameWithPrefix(int id)
{
string name = string.Empty;
if (id > 0)
{
name = this._entityRepository.GetName(id);
}
return "Mr. " + name;
}
}
public interface IEntityRepository
{
string GetName(int id);
}
public class EntityRepository:IEntityRepository
{
public string GetName(int id)
{
// Code to connect to DB and get name based on Id
return "NameFromDb";
}
}
Yes you should call the assert.
VerifyAll() will assert that all SetUp() calls were actually called.
VerifyAll() will not confirm that your student object is registered. Because there are no SetUp() calls in your test case, I think VerifyAll() isn't verifying anything.
I would absolutely expect to see Verify and Assert used side-by-side within a unit test. Asserts are used to validate that properties of your system under test have been set correctly, whereas Verify is used to ensure that any dependencies that your system under test takes in have been called correctly. When using Moq I tend to err on the side of explicitly verifying a setup rather than using the VerifyAll catch-all. That way you can make the intent of the test much clearer.
I'm assuming in the code above that your call to the student repository returns a boolean to state that the student is registered? And you then set that value on the student object? In that case, there is a valuable setup that needs to be added, in which you are effectively saying that when the student repository method is called, it will return true. Then you Assert that student.IsRegistered is true to ensure that you have set the property correctly from the repository return value and you Verify that the repository method is called with the inputs that you are expecting.
There's nothing intrinsically wrong with both asserting and verifying in a mocking test, though assertions that depend on the actual methods being called are likely to fail, because the mock methods do not have the same effects as the real methods.
In your example it is probably fine, as only the repository is mocked, and the change of the student state is presumably done in the service.
Whether both verify and assert should be done in the same test is to a degree a matter of taste. Really the verify is checking that the proper calls to the repository are made, and the assert is checking that the proper change to the entity is made. As these are separate concerns, I'd put them in separate tests, but that may just be me.
I have a very different kind of method call which I need to test using JMockit testing framework. First let us look at the code.
public class MyClass{
MyPort port;
public registerMethod(){
Holder<String> status=null;
Holder<String> message=null;
//below method call is a call to a webservice in the real implementation using apache cxf framework. This method has a void return type. Read below for better explanation.
port.registerService("name", "country", "email", status, message);
// do some stuff with status and message here.....
HashMap response = new HashMap();
response.put(status);
response.put(message);
return response;
}
}
Now let me explain the a little bit. This class is basically having a port instance variable which is used to connect to a webservice. The webservice implementation uses auto generated apache cxf framework classes to make connection to the webservice and get the response back. My job is to implement the mocking of this webservice call for writing testcases for lot many similar calls that are there in the real application.
The problem here is - If you notice that call to the webservice is actually made by the method port.registerService by sending name, country and email as the parameters. Now we also pass the status and message variables as the parameters themselves to this method. So this method instead of returning some value for status and message, it FILLS IN values in these two passed parameters which is very different from the "RETURN" approach.
Now the problem is when I m trying to mock this call using jmockit, I can always mock this call but what is to be expected ?? as there is no return at all, it turns out to be a void call which fills in values in the parameters passed to it. So I will always get status, and message as null if I mock this call as I cannot state any return expectation in the jmockit implementation.
Please if anybody has any solutions/suggestions to the above problem, do respond and try to help me. Thanks.
I was not sure what the Holder interface looked like so I made some assumptions. But, this is how you mock a method with a void return type using Mockito:
#SuppressWarnings("unchecked")
#Test
public final void test() {
// given
final String expectedStatus = "status";
final String expectedMessage = "message";
final MyPort mockPort = mock(MyPort.class);
final Answer<Void> registerAnswer = new Answer<Void>() { // actual parameter type doesn't matter because it's a void method
public Void answer(final InvocationOnMock invocation) throws Throwable {
// Here I'm stubbing out the behaviour of registerService
final Object[] arguments = invocation.getArguments();
// I don't actually care about these, but if you wanted the other parameters, this is how you would get them
// if you wanted to, you could perform assertions on them
final String name = (String) arguments[0];
final String country = (String) arguments[1];
final String email = (String) arguments[2];
final Holder<String> statusHolder = (Holder<String>) arguments[3];
final Holder<String> messageHolder = (Holder<String>) arguments[4];
statusHolder.put(expectedStatus);
messageHolder.put(expectedMessage);
// even though it's a void method, we need to return something
return null;
}
};
doAnswer(registerAnswer).when(mockPort).registerService(anyString(),
anyString(), anyString(), any(Holder.class), any(Holder.class));
final MyClass object = new MyClass();
object.port = mockPort;
// when
final Map<String, String> result = object.registerMethod();
// then
assertEquals(expectedStatus, result.get("status"));
assertEquals(expectedMessage, result.get("message"));
}
For reference, these are my imports:
import static org.junit.Assert.assertEquals;
import static org.mockito.Matchers.any;
import static org.mockito.Matchers.anyString;
import static org.mockito.Mockito.doAnswer;
import static org.mockito.Mockito.mock;
import java.util.HashMap;
import java.util.Map;
import org.junit.Test;
import org.mockito.invocation.InvocationOnMock;
import org.mockito.stubbing.Answer;