Question

Okay, so this might be a dangerous question to ask. I have been doing unit testing for a while, but for some reason, I woke up this morning and I asked myself this question.

Say I have an interface UserFactory, and it has the method CreateUser.

At some point I need to create a user right? So I create a test checking whether CreateUser was called for the UserFactory at the appropriate place.

Now, unit tests are pretty coupled to the actual code – which is fine. But maybe a bit too much? As in, the only way to break the test is by not calling the call to CreateUser. We are not checking its implementation etc. but just checking the interface has been called. But whoever does remove that call, would have a failing test and ultimately remove the verify statement from the step to verify the CreateUser was called.

I have seen this happen over and over again.

Could someone bring the light back to me and explain why is it beneficial to verify mocked objects’ methods have been called? I can see why it may be useful to set them up, say CreateUser should return a dummy user for later part of the code, but in places where we are simply and only verify if they have been called is the part that got me.

Thanks!

Answer 1

Verifying a mocked object is often a necessary evil and, as you mentioned, unit tests sometimes are really tightly coupled to the class under test.

I don’t know how to give a good answer to your question, but I’ll try.

Take this bit of code as an example, where userRepository is a dependency (the example is not exactly great).

public void doSomething(User user) {
    if( user.isValid() ) {
        userRepository.save(user)
    } else {
        user.invalidate();
    }
}

One way to test this, would be to plug the real repository, which connects to the DB, and verify that the user is persisted. But since I’m unit testing, I can’t have an external dependency in my test.

Now, which other options do you have to verify the scenario where the user is valid? Since userRepository.save() returns void, the only way is to verify the side effect is to verify that the mock was called.
If I wouldn’t verify the mock, then the unit test wouldn’t be very good, as I could delete the line where I save the object, and the test would still pass.

This is not the case with some mocks that return a value, and then than value is used in the method. This usually means that if the mock returns a null, then the application throws a NullPointerException (in the case of java).