Mocking Objects To Unit Test Android OS Applications

First Things First
Testing applications for Android OS can be done in two ways:

• test on the Android platform using android.test and android.test.mock classes, or
• testing on the development machine using the regular Java VM and standard Java unit testing and object mocking frameworks.

The good discussion as to pros and cons of each is presented in this article by a Google developer (although not an Android developer). The conclusion was to use the second option, due to valid limitations ofTo the first approach.

Mocking

What are mock objects? They are fake objects that can pretend to the callers to be an object they pretend to be, but are under full control of the test. Full control means two things here:

• The test can monitor what methods of a mock object are called during the test and what parameters are provided, and
• The test can dictate what results a mock class should return, without having to actually use, or even implement the class that is mocked.
  

Why mock objects? Without mocking objects, unit testing is limited to cases where the class under test doesn't use any other classes, or may be just some basic classes. The fuller answer is to why, can be given the following answers. To simplify explaining these answers, let's assume that we want to test class A which uses class B:

• If some of the class A results depend on class B results. Without using mocking, the test would include the testing of class B. Often, we want to be able to write a test that tests just a single class. Smaller tests can be less brittle, that is they don't break as often with the changes done to the code after the test has been written.
• If using class B in the test environment is not practical. For example, if the class B is a database, a web service or a GPS module, both of which are tightly coupled to the real world.
• If we want to test class A before class B is implemented, so it doesn't exists, yet.
• In general, mocking allows us to test not only an internal code of class A, but also if it uses class B correctly. So, it tests the class collaboration.

For more info on this topic see wikipedia article or this.

What Tools Are Available for Mocking?
The least of tools is quite long. In last couple years, I used probably the following ones:

• JMock
• Easy Mock
• Mockito
• PowerMock

The reasons I moved from one framework to another are new features (PowerMock can mock even static and final methods) and simpler syntax/tests (esp. Mockito). Also, PowerMock is in a way a conglomerate of Mockito and EasyMock. Although, that means that sometimes, when you use PowerMock you have to use the Mockito, and sometimes the EasyMock like API's. The good part is, that onces you know what mocking is about, using different API's is not that different.

FlexUnit Plugin for Eclipse

Since we intend to do unit testing in our Flex+Java development, I have been playing with FlexUnit and have found an eclipse plugin that makes it easier to use (also, in plugin central). Here's a summary and lessons learned on how to start with the plugin

Installation
Follow the installation instructions from here. Once installed, open the plugin's help in Eclipse and configure it. A few points:

• Download FlexUnit and FlexUnit extension for the plugin.
• You will need to have Flex Builder 3.
  
• You will need a debugger version of Flash Player (I used version 10). A standalone player used by the plugin comes with Flex Builder (directory: player)
  
• Follows instructions from Adobe on how to enable logging and error output for Flash Player. When you follow them, after you create a mm.cfg file, you will need to restart all instances of Flash Player for the Logs folder to show up.

Using The Plugin
To use a plugin:

• Create a unit test using Flex Builder's wizard. I recommend keeping them in another source folder, so they can be easily skipped when releasing the app. For example, keep the flex source in flex-src and flex tests in flex-test. The server code put in java-src and java-test, or whatever language you use for the middle-tier.
• Create a harness. Right click in the test file in the project navigator, find FlexUnit menu and select Create Harness. This will create a small mxml file for your test. However, if you use FlexUnit 0.9, the code needs a correction. Replace:

  EclipsePluginTestRunner.runTests( new Array(AccountTest.suite()) );

  with

  EclipsePluginTestRunner.run( AccountTest.suite() );

• Run the test. Right click on the harness file and select Run from the FlexUnit menu. Observer the test results on the nice eclipse viewer.
  

I had the problem that the test launch process never finishes in eclipse. But it doesn't seem to be harmful. Just ignore it.

Summary
It's a great plugin. It could do quite a bit more, but it's a great start. It worked for me with a FlexUnit 4, when I used the syntax of FlexUnit 0.9. When I switched to FlexUnit 4 syntax, I didn't have to apply the correction mentioned above to the auto-generated harness to compile. However, I didn't get my tests executed. So, I guess, for now, using the FlexUnit 0.9 is a better option. However, I have heard from the plugin author that he intends to do another release of the plugin.