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
Due to the dynamic nature of Objective-C, it works great!
1 2 3 4 5 6
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.