Cleaner interaction tests

by | Jan 26, 2012 | Software Development, Test Driven Development | 4 comments

Note: this post will probably evolve, the text will be updated as I need it.

In order to write cleaner interaction tests (those which use test doubles; mocks, spies, stubs) you should understand how your test doubles framework works. Interaction tests can be extremely difficult to read and maintain and very fragile if you don’t pay enough attention. We will review Mockito, Moq, Jasmine and pyDoubles.

Mockito and Moq create a double object by inheriting the original and overriding its methods. pyDoubles uses interception rather than inheritance. Jasmine is different because it does not double the whole object, but just the method you spy on. So there is a big difference: Mockito, Moq and pyDoubles replace the whole object while Jasmine replaces just one method.

So Jasmine leaves space for a bad testing practice: Spy on one method of the object while testing other method of the same object. Interaction tests are intentded for object collaboration. Testing that one method calls another method within the same object is not recommended. It means that the object has more than one responsibility or that you want to know more about the object’s inner behavior than you should, so you are breaking encapsulation. This is not a Jasmine problem, the problem is yours if you don’t use the tool properly.

There are three primary reasons to replace method calls on collaborators:

  1. You want to avoid a database call just to keep the test unit fast and repeatable (stub the method – use a stub object)
  2. You want the method to return some value to simulate the response (stub the method – use a stub object)
  3. You want to make sure that a call is made (spy or expect the call – use a spy or a mock object)

For case numer 1, you don’t have to specify the returned value. Just use the stub object and let the framework return whatever it wants. Mockito and Moq, return the default value for the method, when no other behavior is specified:

  • If the method returns an integer, a call to that method in the stub object, will return cero (default value for integers)
  • If the method returns an object (reference type), a call to the stub method will return null (default for objects)
  • False for booleans and so on…

However, be careful with Moq because in C#, if the original method is not virtual (contains the virtual keyword), Moq can’t stub it out, so the original will be called. Moq fails if you specify a behavior on that method but if you don’t, it calls the original instead of returning the default value.

pyDoubles always returns None no matter the method signature.

For case numer 2, you define what the returned value should be. Using “when” in Mockito and “Setup” in Moq.

For case numer 3, you verify that a call was made:

  • Mockito: verify(double).method();
  • Moq: double.Verify(x=>x.method());
  • pyDoubles: assert_that_method(double.method).was_called()
  • Jasmine: expect(double.method).toHaveBeenCalled()

You might want to know what parameters were passed in too. In this case you can use Matchers in Mockito, Moq and pyDoubles.

Moq sample:

userRepository.Verify(x => x.SaveNewUser(
        It.Is(
        p => p.PersonalIdentificationCode == "TEST_CODE")));

pyDoubles sample:

assert_that_method(double.method
         ).was_called().with_args(obj_with_fields({
                            'id': 20,
                            'test_field': 'OK'}))

For Mockito samples I am waiting for my friend @regiluze to write a post on it 🙂 I will link it here when written.

Jasmine sample:

spyOn(double, "method").andCallFake(function(){
      expect(arguments[0].name).toEqual("Carlos");
});

Test collaborations one to one:

If the object under test has more than one collaborator, tests can be really hard to understand. I recommend expressing every collaboration in a single test:

  • A talks to B (test 1)
  • A talks to C (test 2)
  • For test1, B will be a spy o mock (you use Verify at the end). Also for test1, you don’t care about C, C is just a dummy. Calls to C don’t need to be configured in the double, let the framework return the default value.
  • For test2, C is the spy or the mock, you verify interaction between A and C, and do’t care about B. Calls to B don’t need to be configured, let the framework return whatever.
  • For test1, if the value returned by C, is necessary for the collaboration between A and B, then Ok, specify the stub result for that call to C, and verify on B.

Group the tests by setup:

Should I have a test class for every class in the production code? NO.  Tests must be grouped by their setup. This is, put those which have the same arrangement in the same test case (test class). If there are two or more interaction tests in a class, the creation of the SUT and the doubles, should not be in every test. It must be in the setup, along with the injection (doubles, are injected to the SUT as collaborator). So, if you find yourself injecting the test double to the SUT in more than one test, watch them again carefully.