Content providers, which store and retrieve data and make it accessible across applications, are a key part of the Android API. As an application developer you're allowed to provide your own public providers for use by other applications. If you do, then you should test them using the API you publish.
This document describes how to test public content providers, although the information is also applicable to providers that you keep private to your own application. If you aren't familiar with content providers or the Android testing framework, please read Content Providers, the guide to developing content providers, and Testing Fundamentals, the introduction to the Android testing and instrumentation framework.
In Android, content providers are viewed externally as data APIs that provide tables of data, with their internals hidden from view. A content provider may have many public constants, but it usually has few if any public methods and no public variables. This suggests that you should write your tests based only on the provider's public members. A content provider that is designed like this is offering a contract between itself and its users.
The base test case class for content providers,
ProviderTestCase2, allows you to test your content provider in an isolated environment. Android mock objects such as
MockContentResolver also help provide an isolated test environment.
As with other Android tests, provider test packages are run under the control of the test runner
InstrumentationTestRunner. The section Running Tests With InstrumentationTestRunner describes the test runner in more detail. The topic Testing in Eclipse, with ADT shows you how to run a test package in Eclipse, and the topic Testing in Other IDEs shows you how to run a test package from the command line.
The main focus of the provider testing API is to provide an isolated testing environment. This ensures that tests always run against data dependencies set explicitly in the test case. It also prevents tests from modifying actual user data. For example, you want to avoid writing a test that fails because there was data left over from a previous test, and you want to avoid adding or deleting contact information in a actual provider.
The test case class and mock object classes for provider testing set up this isolated testing environment for you.
You test a provider with a subclass of
ProviderTestCase2. This base class extends
AndroidTestCase, so it provides the JUnit testing framework as well as Android-specific methods for testing application permissions. The most important feature of this class is its initialization, which creates the isolated test environment.
The initialization is done in the constructor for
ProviderTestCase2, which subclasses call in their own constructors. The
ProviderTestCase2 constructor creates an
IsolatedContext object that allows file and database operations but stubs out other interactions with the Android system. The file and database operations themselves take place in a directory that is local to the device or emulator and has a special prefix.
Lastly, the constructor creates an instance of the provider under test. This is a normal
ContentProvider object, but it takes all of its environment information from the
IsolatedContext, so it is restricted to working in the isolated test environment. All of the tests done in the test case class run against this isolated object.
The topic What To Test lists general considerations for testing Android components. Here are some specific guidelines for testing content providers.
ProviderTestCase2, you should always test with a resolver object using the appropriate URI. This ensures that you are testing the provider using the same interaction that a regular application would use.
If you want a step-by-step introduction to testing activities, try one of the testing tutorials: