콘텐츠로 건너뛰기

자주 방문한 페이지

최근 방문한 페이지

navigation

Testing Your Content Provider

Dependencies and Prerequisites

This lesson teaches you to

  1. Create Integration Tests for Content Providers
  2. What to Test

You should also read

If you are implementing a content provider to store and retrieve data or to make data accessible to other apps, you should test your provider to ensure that it doesn't behave in an unexpected way. This lesson describes how to test public content providers, and is also applicable to providers that you keep private to your own app.

Create Integration Tests for Content Providers

In Android, apps view content providers 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. For this reason, 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.

Content providers let you access actual user data, so it's important to ensure that you test the content provider in an isolated testing environment. This approach allows you to only run against data dependencies set explicitly in the test case. It also means that your tests do not modify actual user data. For example, you should avoid writing a test that fails because there was data left over from a previous test. Similarly, your test should avoid adding or deleting actual contact information in a provider.

To test your content provider in isolation, use the ProviderTestCase2 class. This class allows you to use Android mock object classes such as IsolatedContext and MockContentResolver to access file and database information without affecting the actual user data.

Your integration test should be written as a JUnit 4 test class. To learn more about creating JUnit 4 test classes and using JUnit 4 assertions, see Create a Local Unit Test Class.

To create an integration test for your content provider, you must perform these steps:

How ProviderTestCase2 works

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.

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.

You run integration tests for content providers the same way as instrumented unit tests. To run the integration test for your content provider, follow the steps described in Run Instrumented Unit Tests.

What to Test

Here are some specific guidelines for testing content providers.

이 사이트는 쿠키를 사용하여 사이트별 언어 및 표시 옵션에 대한 환경설정을 저장합니다.

Google Play에서 성공을 거두는 데 도움이 되는 최신 Android 개발자 뉴스 및 도움말을 받아 보세요.

* 필수 입력란

완료되었습니다.

WeChat에서 Google Developers 팔로우하기

이 사이트를 (으)로 탐색할까요?

페이지를 요청했지만 이 사이트의 언어 환경설정은 입니다.

언어 환경설정을 변경하고 이 사이트를 (으)로 탐색할까요? 언어 환경설정을 나중에 변경하려면 각 페이지 하단의 언어 메뉴를 사용하세요.

이 클래스를 사용하려면 API 수준 이상이 필요합니다.

문서에 대해 선택한 API 수준이 이므로 이 문서가 표시되지 않습니다. 왼쪽 탐색 메뉴의 선택기로 문서 API 수준을 변경할 수 있습니다.

앱에 필요한 API 수준 지정에 관한 자세한 내용은 다양한 플랫폼 버전 지원을 참조하세요.

Take a short survey?
Help us improve the Android developer experience. (April 2018 — Developer Survey)