skip to main |
skip to sidebar
Content Provider Testing API
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.
ProviderTestCase2
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.
The constructor then creates a MockContentResolver to use as the
resolver for the test. The MockContentResolver class is described in
detail in the section
Mock object
classes.
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.
Content Provider Design and Testing
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 IsolatedContext and
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 From Eclipse with ADT shows you how to run a test package in Eclipse, and the
topic
Testing From Other IDEs
shows you how to run a test package from the command line
ProviderTestCase2
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.
The constructor then creates a MockContentResolver to use as the
resolver for the test. The MockContentResolver class is described in
detail in the section
Mock object
classes.
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.