Friday, November 13, 2009

Android Testing: Mock Contexts

AndroidTesting: Mock Context
















This document can be read in Google Docs (http://docs.google.com/View?id=ddwc44gs_21737cgtvfj), cut and paste link if you have problems accessing it.







Continuing with our Android Testing series, we take a short detour before we proceed to create more unit and functional tests.

We have visited Mock Objects before and evaluated our Test Driven Development purism and the concerns about not using real objects, but this is another discussion.

Sometimes, introducing mock objects in our tests is recommended, desirable, useful or even unavoidable.

Android SDK provides some classes to help us in this quest in the package android.test.mock:







mock context overview


Mock Context class implements all methods in a non-functional way and throw UnsopportedOperationException.

This can be used to inject other dependencies, mocks, or monitors into the classes under testing. A fine control can be obtained extending this class.



Extend this class to provide your desired behaviour overriding the correspondent methods.





mocking file and database operations


In some cases, all we need is to be able to mock the file and database operations. For example, if we are testing the application on a real device perhaps we don't want to affect existing files during our tests.

Such cases can take advantage of another class that is not part of the android.test.mock package but of android.test instead, that is RenamingDelegatingContext. I think it belongs to the former but it is in the parent package for apparently no reason.

This class let us mock operations and files and databases are prefixed by a prefix that is specified in the constructor. All other operations are delegated to the delegating Context that you must specify in the constructor too.



Suppose our Activity under test uses some files we want to control in some way, maybe introducing specialised content to drive our tests and we don't want or we can't use the real files, in this case we create a RenamingDelegatingContext specifying a pefix, we provide that files, and our unchanged Activity will use them.



Our Activity under test, MockContextExamplesActivity, displays the content of a file inside a TextView, what we intend is to be able to display different content during a test than during normal operation of the Activity.



MockContextExamplesActivity.java


A very simple Activity. Shows the content of the file myfile.txt inside a TextView.
















package com.codtech.android.training.mockcontext.examples;



import java.io.FileInputStream;

import java.io.FileNotFoundException;

import java.io.IOException;



import android.app.Activity;

import android.graphics.Color;

import android.os.Bundle;

import android.widget.TextView;



public class MockContextExamplesActivity extends Activity {

    public final static String FILE_NAME = "myfile.txt";

    

    private TextView tv;

    

    /** Called when the activity is first created. */

    @Override

    public void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        setContentView(R.layout.main);

        

        tv = (TextView) findViewById(R.id.TextView);

        final byte[] buffer = new byte[1024];

        

        try {

            final FileInputStream fis = openFileInput(FILE_NAME);

            final int n = fis.read(buffer);

            tv.setText(new String(buffer, 0, n-1));

        } catch (Exception e) {

            tv.setText(e.toString());

            tv.setTextColor(Color.RED);

        }

    }

    

    public String getText() {

        return tv.getText().toString();

    }

}






MyMockContext.java















import java.io.FileInputStream;

import java.io.FileNotFoundException;

import java.io.FileOutputStream;



import android.content.Context;

import android.test.RenamingDelegatingContext;

import android.util.Log;





/**

 * @author diego

 *

 */

public class MyMockContext extends RenamingDelegatingContext {

    private static final String TAG = "MyMockContext";

    

    private static final String MOCK_FILE_PREFIX = "test.";





    /**

     * @param context

     * @param filePrefix

     */

    public MyMockContext(Context context) {

        super(context, MOCK_FILE_PREFIX);

        makeExistingFilesAndDbsAccessible();

    }



    /* (non-Javadoc)

     * @see android.test.RenamingDelegatingContext#openFileInput(java.lang.String)

     */

    @Override

    public FileInputStream openFileInput(String name)

            throws FileNotFoundException {

        Log.d(TAG, "actual location of " + name +

            " is " + getFileStreamPath(name));

        return super.openFileInput(name);

    }



    /* (non-Javadoc)

     * @see android.test.RenamingDelegatingContext#openFileOutput(java.lang.String, int)

     */

    @Override

    public FileOutputStream openFileOutput(String name, int mode)

            throws FileNotFoundException {

        Log.d(TAG, "actual location of " + name +

            " is " + getFileStreamPath(name));

        return super.openFileOutput(name, mode);

    }

}









test.myfile.txt


We also need to provide at least the text file containing the sample text.

The directory where these files are located is created during package installation, so you may want to wait till you install the package for the first time to run this command.

Notice that we are using a "test." prefix in this file creation as we did in our MyMockContext class.

To do this just run this command:
















diego@bruce:\~$ adb shell echo "This is sample text" \

   \> /data/data/com.codtech.android.training.mockcontext.examples/files/test.myfile.txt





Remember to change package name if you are using a different one.



If you also want to create some real context to be displayed by the Activity use this command:
















diego@bruce:\~$ adb shell echo "This is REAL text" \

   \> /data/data/com.codtech.android.training.mockcontext.examples/files/myfile.txt





Notice that here there's no "test." prefix because it's the real file.





MockContextExamplesTest.java


Now when we create some tests we can use this mock context.
















import android.content.Context;

import android.content.Intent;

import android.test.ActivityUnitTestCase;



import com.codtech.android.training.mockcontext.examples.MockContextExamplesActivity;



/**

 * @author diego

 *

 */

public class MockContextExamplesTests extends ActivityUnitTestCase<MockContextExamplesActivity> {



    public MockContextExamplesTests() {

        super(MockContextExamplesActivity.class);

    }



    /**

     * @throws java.lang.Exception

     */

    protected void setUp() throws Exception {

    }



    /**

     * @throws java.lang.Exception

     */

    protected void tearDown() throws Exception {

    }



    public void testSampleTextDisplayed() {

        // mock context

        Context mockContext = new MyMockContext(getInstrumentation().getTargetContext());

        setActivityContext(mockContext);

        startActivity(new Intent(), null, null);

        final MockContextExamplesActivity activity = getActivity();

        assertNotNull(activity);

        assertEquals("This is sample text", activity.getText());

    }

    

    public void testRealTextDisplayed() {

        // real context

        setActivityContext(getInstrumentation().getTargetContext());

        startActivity(new Intent(), null, null);

        final MockContextExamplesActivity activity = getActivity();

        assertNotNull(activity);

        assertFalse("This is sample text".equals(activity.getText()));

    }

}












Conclusion


Though this is an oversimplified example it shows the most important concepts behind Mock Contexts and the way you can use Delegating Context to isolate your Activity from other parts of the system like the filesystem in this case.






Copyright © 2009 Diego Torres Milano. All rights reserved.

























































Friday, November 06, 2009

Android Testing: Instrumentation name

I was asked this question many times, so I think it should be present in a kind of FAQ in the future. Meanwhile...

Q: Where does the Instrumentation name come from ?
We here refer to the name that appears on the Instrumentation list in DevTools -> Instrumentation as showed in this screenshot.
By default we see android.test.InstrumentationTestRunner for all of our tests, so it would be very difficult to identify them


A: From the attributes of android.test.InstrumentationTestRunner in AndroidManifest.xml
That is, if the Label is not set in the manifest the default name is used. To set something meaningful for your tests set the label. In this case we shot Eclipse Android ADT manifest editor screen.

Wednesday, October 28, 2009

Upgrading to android SDK 2.0

This time the upgrade is much simpler than with previous versions. Upgrading is now supported from inside android tools itself.
Assuming you have already configured your installation to be able to install as root and run as unprivileged users as was described in previous posts, upgrading is a simple task, just run

$ sudo android


the select the desired components to install (i.e.: SDK Platform Android 2.0) and click Install Selected

Once you upgrade you still need to fix the permissions again, to do it run

$ wget -qO - http://android.codtech.com/android-tools/android-fixperms | sudo bash -s -- --sdk --sdk-dir=/opt/android

If you have installed android SDK to a different directory replace /opt/android in previous command by the correct location.

Hope this helps.

Tuesday, October 27, 2009

Japan Linux Symposium 2009 pictures





Photos from the Japan Linux Symposium. Some of them were taken at the VIP Reception at the MADO LOUNGE, which is located on the 52nd floor of Mori Tower in the Roppongi Hills. From 250 meters above sea-level, you can enjoy amazing views of Tokyo.

One of the photos taken by Keiko, who sent me the photo later, shows Klaas, Linus and me. There are other photos of Tokyo from the tower. They were taken with my Android HTC Hero, so you may understand they are not the best.
Finally, photos from the presentation that were kindly taken by Scott Trent.

Sunday, October 25, 2009

Android Tutorial at 1st Japan Linux Symposium

I would like to thank Linux Foundation for the invitation to present the Android Tutorial at the 1st Japan Linux Symposium.
A successful event indeed, and I was gladly surprised by all the interest in Android development attendees demonstrated.
Some requested me the presentation slides and I wrongly assumed they could be located at the official site. My fault. Anyway, you can find the presentation and other resources at http://android.codtech.com/jls2009 or if you prefer at slideshare.

This newest Linux Foundation event in Asia Pacific brought together developers, managers, executives, students and end users from Japan, Korea, China and many International countries.

I have had a great time in Tokyo and I hope to be here for 2010 too.

I would also thank Scott Trent, who took this and other great pictures of the event. You can find them at day 1, day 2 and day 3.

Friday, October 09, 2009

Android SDK: one step closer

Starting with the latest android 1.6 SDK release 1, Google is distributing the Linux version as a TGZ file instead of ZIP.
We mentioned the problem of distributing the Linux version as a ZIP file in previous posts, loosing ownerships and file permissions is a problem when you install the SDK or NDK in a multiuser environment.

Well, we are halfway there, still there's some permission problems that you can fix using android-fixperms that can be downloaded from this site.

Use it like this, for example to change the SDK installed at /opt/android-sdk-linux_x86-1.6_r1

$ android-fixperms --sdk --sdk-dir=/opt/android-sdk-linux_x86-1.6_r1

Hope this helps.

Wednesday, September 23, 2009

Android: android.process.acore has stopped

I've started to receive the infamous message: The process android.process.acore has stopped unexpectedly. Please try again. Is this the android counterpart of the blue screen of death ?


Lately I'm receiving this annoyingly often. Googling for it you can find some links giving some solutions I found unacceptable like hardware resetting the phone.

Notice: There could be many causes for this problem, so follow the steps presented here to determine if you are in this case.

Hence, I decided to take some action and find the reason. After some debugging this is what I've found:
09-23 16:32:13.798: DEBUG/Sync(110): skipping photo edit for unsynced contact
09-23 16:32:13.938: WARN/dalvikvm(110): threadid=37: thread exiting with uncaught exception (group=0x4000fe70)
09-23 16:32:13.938: ERROR/AndroidRuntime(110): Uncaught handler: thread SyncThread exiting due to uncaught exception
09-23 16:32:13.948: ERROR/AndroidRuntime(110): java.lang.NullPointerException
09-23 16:32:13.948: ERROR/AndroidRuntime(110): at com.android.providers.contacts.ContactsSyncAdapter.cursorToContactsElement(ContactsSyncAdapter.java:846)

Unfortunately the problem, a NullPointerException, is in ContactsSyncAdapter.java, a piece of Google maintained code AFAIK and we can only watch it happens and no much more than finding a workaround. Before introducing the workaround let's analyze one of the possible reasons for this problem.

Last message before the exception is

skipping photo edit for unsynced contact

so the problem might be an edition of a contact photo that can't be synced.

On possible workaround is to disable Auto-sync for Google data.
Try to synchronize Gmail, Calendar and Contacts and check if you receive the android.process.acore has stopped unexpectedly message.

Fortunately you can just disable Contacts synchronization. You should remember to synchronize manually your Contacts data until you find another solution, an upgrade is provided by Google, you can delete all of your Contacts and hope for the best or hard reset your phone.


Hope this helps.