Automated software testing on mobile platforms (iOS and Android) is luckily becoming more and more prevalent. There is a number of frameworks on both platforms for unit testing, integration testing, BDD, and so on.

And here’s a topic I bumped into recently: partial mocks. In a nutshell, you can mock only certain methods of an object, whereas all the other ones are real.

In OCMock for iOS they can be used like this:

1
2
3
4
5
6

// creating
Controller *controller = [Controller new];
id controllerMock = [OCMockObject partialMockForObject:controller];

// stubbing
[[[controllerMock stub] andReturn:@42] theAnswer];

Due to the dynamic nature of Objective-C, it works great!

In Mockito for Android they are called spies. Sample:

1
2
3
4
5
6

// creating
Controller ctrl = new Controller();
Controller ctrlSpy = spy(ctrl);

// stubbing
when(ctrlSpy.theAnswer()).thenReturn(42);

Here, the theAnswer() method is package-local, and I stumbled upon the java.lang.IllegalAccessError: tried to access method Controller.theAnswer() from class Controller_Proxy exception at runtime. Here’s a ticket: http://code.google.com/p/dexmaker/issues/detail?id=26. There is no easy and convenient solution to that.

And that lead me to this thought: this theAnswer() method and the related ones should probably be extracted into its own class. That class should implement a newly created interface, allowing to easily mock it without hassle. The bigger concept is called Dependency Injection. Yes, it may seem a bit unnatural to open the hidden (encapsulated) fields and methods, but that allows you to simplify and decouple the classes.

To sum up, if you find yourself thinking about a partial mock for your class, you may think a bit more about and redesign it. The resulted classes will be more focused on the single functionality they should do well.