コンテンツ プロバイダをテストする
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
データの保存と取得、または新しいコンテンツ配信用のコンテンツ プロバイダを実装する場合は、
他のアプリがデータにアクセスできるようにするには、プロバイダをテストして、
予期しない動作は発生しません。このレッスンでは、
。
開発できます
コンテンツ プロバイダの統合テストを作成する
コンテンツ プロバイダを使用すると実際のユーザーデータにアクセスできるため、
隔離されたテスト環境でコンテンツ プロバイダをテストできます。この
明示的に設定されたデータの依存関係に対してのみ実行し、
テストケースですまた、テストによって実際のユーザーデータが変更されないことも意味します。対象
データが残っているために失敗するテストは作成しないようにします。
ロールバックできます。同様に、コードの追加や削除も避けてください。
連絡先情報をプロバイダに入力する必要があります。
コンテンツ プロバイダを単独でテストするには、ProviderTestCase2
を使用します。
クラスです。このクラスを使用すると、次のような Android モック オブジェクト クラスを使用できます。
IsolatedContext
と MockContentResolver
でファイルと
実際のユーザーデータには影響を与えません。
統合テストは、JUnit 4 テストクラスとして作成する必要があります。関連資料
JUnit 4 テストクラスの作成と JUnit 4 アサーションの使用方法の詳細については、
ローカル単体テストクラス。
コンテンツ プロバイダの統合テストを作成するには、次のことを行う必要があります。
手順:
- テストクラスを
ProviderTestCase2
のサブクラスとして作成します。
- AndroidX Test が提供する
AndroidJUnitRunner
クラスを指定します。
デフォルトのテストランナーとして設定できます。
ApplicationProvider
クラスの Context
オブジェクトを設定します。詳しくは、
スニペットをご覧ください。
Kotlin
@Throws(Exception::class)
override fun setUp() {
super.setUp()
context = ApplicationProvider.getApplicationContext<Context>()
}
Java
@Override
protected void setUp() throws Exception {
super.setUp();
setContext(ApplicationProvider.getApplicationContext());
}
ProviderTestCase2 の仕組み
ProviderTestCase2
のサブクラスでプロバイダをテストします。この基本クラス
AndroidTestCase
を拡張しているため、JUnit テスト フレームワークとして
アプリの権限をテストするための Android 固有のメソッドもあります。最も
初期化は、このクラスで重要な機能の一つです。これにより、
隔離されたテスト環境で行えます
初期化
初期化は ProviderTestCase2
のコンストラクタで行われます。
サブクラスがそれぞれのコンストラクタで呼び出します。ProviderTestCase2
コンストラクタは、ファイルとバケットへのアクセスを許可する IsolatedContext
オブジェクトを作成します。
Android システムとのその他のインタラクションはスタブ化します。
ファイルとデータベースの操作自体は、
デバイスまたはエミュレータに対してローカルであり、特殊な接頭辞を持ちます。
次にコンストラクタは、リゾルバとして使用する MockContentResolver
を作成します。
使用します。
最後に、コンストラクタはテスト対象のプロバイダのインスタンスを作成します。これは、
通常の ContentProvider
オブジェクトですが、このオブジェクトは環境全体を
IsolatedContext
から取得するため、入力できるのは
隔離されたテスト環境で実施できますテストケース クラスで実行されるすべてのテスト
コピーされます。
インストルメンテーション テストと同じ方法でコンテンツ プロバイダの統合テストを実施する
単体テストです。
テスト項目
コンテンツ プロバイダをテストする場合の具体的なガイドラインは次のとおりです。
- リゾルバ メソッドによるテスト: プロバイダをインスタンス化できる場合でも
オブジェクト
ProviderTestCase2
では、常に次のコマンドを使用してリゾルバ オブジェクトでテストする必要があります。
指定します。そうすれば、プロバイダをテストする際に、
通常のアプリケーションと同じインタラクションを実行するだけです。
- パブリック プロバイダをコントラクトとしてテストする: プロバイダを
他のアプリケーションに公開されている場合は、コントラクトとしてテストする必要があります。
方法の例を以下に示します。
<ph type="x-smartling-placeholder">
</ph>
- プロバイダが一般公開している定数でテストします。たとえば、
を使用します。
それは必ず、プロバイダによってパブリックに定義された定数でなければなりません。
- プロバイダが提供するすべての URI をテストします。プロバイダによっては、
URI。それぞれがデータの異なる側面を参照します。
- 無効な URI をテストします。単体テストでは、意図的にプロバイダを呼び出す必要があります。
エラーがないか調べます。優れたプロバイダ設計では、
無効な URI の場合は
IllegalArgumentException
。
- プロバイダの標準的な相互作用をテストする: ほとんどのプロバイダは 6 つのアクセスを提供しています。
メソッド:
query()
、insert()
、delete()
、update()
、getType()
、
onCreate()
。テストでは、これらの方法がすべて機能することを確認する必要があります。
- ビジネス ロジックのテスト: コンテンツ プロバイダがビジネス ロジックを実装している場合は、
テストする必要がありますビジネス ロジックには、無効な値の処理、財務イベント、
重複の除去、結合などの操作が含まれます。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-07-27 UTC。"],[],[],null,["# Test content providers\n\nIf you are implementing a [content provider](/guide/topics/providers/content-providers) to store and retrieve data or to\nmake data accessible to other apps, you should test your provider to ensure that\nit doesn't behave in an unexpected way. This lesson describes how to test public\ncontent providers, and is also applicable to providers that you keep private to\nyour own app.\n\nCreate integration tests for content providers\n----------------------------------------------\n\nContent providers let you access actual user data, so it's important to ensure\nthat you test the content provider in an isolated testing environment. This\napproach allows you to only run against data dependencies set explicitly in the\ntest case. It also means that your tests do not modify actual user data. For\nexample, you should avoid writing a test that fails because there was data left\nover from a previous test. Similarly, your test should avoid adding or deleting\nactual contact information in a provider.\n| **Note:** This document focuses on [`ProviderTestCase2`](/reference/android/test/ProviderTestCase2) which is being replaced by the experimental [`ProviderTestRule`](/reference/androidx/test/rule/provider/ProviderTestRule).\n\nTo test your content provider in isolation, use the `ProviderTestCase2`\nclass. This class allows you to use Android mock object classes such as\n[`IsolatedContext`](/reference/android/test/IsolatedContext) and [`MockContentResolver`](/reference/android/test/mock/MockContentResolver) to access file and\ndatabase information without affecting the actual user data.\n\nYour integration test should be written as a JUnit 4 test class. To learn more\nabout creating JUnit 4 test classes and using JUnit 4 assertions, see [Create a\nLocal Unit Test Class](/training/testing/local-tests#test-class).\n\nTo create an integration test for your content provider, you must perform these\nsteps:\n\n1. Create your test class as a subclass of `ProviderTestCase2`.\n2. Specify the [`AndroidJUnitRunner`](/reference/androidx/test/runner/AndroidJUnitRunner) class that [AndroidX Test](/training/testing) provides as your default test runner.\n3. Set the [`Context`](/reference/android/content/Context) object from the `ApplicationProvider` class. See the snippet below for an example.\n\n### Kotlin\n\n```kotlin\n@Throws(Exception::class)\noverride fun setUp() {\n super.setUp()\n context = ApplicationProvider.getApplicationContext\u003cContext\u003e()\n}\n```\n\n### Java\n\n```java\n@Override\nprotected void setUp() throws Exception {\n super.setUp();\n setContext(ApplicationProvider.getApplicationContext());\n}\n```\n\n### How ProviderTestCase2 works\n\nYou test a provider with a subclass of `ProviderTestCase2`. This base class\nextends [`AndroidTestCase`](/reference/android/test/AndroidTestCase), so it provides the JUnit testing framework as\nwell as Android-specific methods for testing application permissions. The most\nimportant feature of this class is its initialization, which creates the\nisolated test environment.\n\n#### Initialization\n\nThe initialization is done in the constructor for `ProviderTestCase2`,\nwhich subclasses call in their own constructors. The `ProviderTestCase2`\nconstructor creates an `IsolatedContext` object that allows file and\ndatabase operations but stubs out other interactions with the Android system.\nThe file and database operations themselves take place in a directory that is\nlocal to the device or emulator and has a special prefix.\n\nThe constructor then creates a `MockContentResolver` to use as the resolver\nfor the test.\n\nLastly, the constructor creates an instance of the provider under test. This is\na normal [`ContentProvider`](/reference/android/content/ContentProvider) object, but it takes all of its environment\ninformation from the `IsolatedContext`, so it is restricted to working in\nthe isolated test environment. All of the tests done in the test case class run\nagainst this isolated object.\n\nYou run integration tests for content providers the same way as instrumented\nunit tests.\n\nWhat to test\n------------\n\nHere are some specific guidelines for testing content providers.\n\n- **Test with resolver methods** : Even though you can instantiate a provider object in `ProviderTestCase2`, you should always test with a resolver object using the appropriate URI. Doing so ensures that you are testing the provider by performing the same interaction that a regular application would use.\n- **Test a public provider as a contract** : If you intend your provider to be public and available to other applications, you should test it as a contract. Some examples of how to do so are as follows:\n - Test with constants that your provider publicly exposes. For example, look for constants that refer to column names in one of the provider's data tables. These should always be constants publicly defined by the provider.\n - Test all the URIs that your provider offers. Your provider may offer several URIs, each one referring to a different aspect of the data.\n - Test invalid URIs. Your unit tests should deliberately call the provider with an invalid URI, and look for errors. A good provider design is to throw an `IllegalArgumentException` for invalid URIs.\n- **Test the standard provider interactions** : Most providers offer six access methods: `query()`, `insert()`, `delete()`, `update()`, `getType()`, and `onCreate()`. Your tests should verify that all of these methods work.\n- **Test business logic**: If the content provider implements business logic, you should test it. Business logic includes handling of invalid values, financial or arithmetic calculations, elimination, or combining of duplicates."]]