ارائه دهندگان محتوا را تست کنید
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
اگر ارائه‌دهنده محتوا را برای ذخیره و بازیابی داده‌ها یا دسترسی به داده‌ها برای سایر برنامه‌ها پیاده‌سازی می‌کنید، باید ارائه‌دهنده خود را آزمایش کنید تا مطمئن شوید که رفتار غیرمنتظره‌ای ندارد. این درس نحوه آزمایش ارائه‌دهندگان محتوای عمومی را توضیح می‌دهد، و همچنین برای ارائه‌دهندگانی که در برنامه خود خصوصی نگه می‌دارید نیز قابل استفاده است.
تست های یکپارچه سازی را برای ارائه دهندگان محتوا ایجاد کنید
ارائه‌دهندگان محتوا به شما امکان دسترسی به داده‌های واقعی کاربر را می‌دهند، بنابراین مهم است که اطمینان حاصل کنید که ارائه‌دهنده محتوا را در یک محیط آزمایشی مجزا آزمایش می‌کنید. این رویکرد به شما اجازه می‌دهد که فقط در برابر وابستگی‌های داده‌ای که به صراحت در مورد تست تنظیم شده‌اند اجرا کنید. همچنین به این معنی است که آزمایشات شما داده های واقعی کاربر را تغییر نمی دهد. به عنوان مثال، شما باید از نوشتن تستی که ناموفق است به دلیل وجود داده های باقی مانده از آزمون قبلی خودداری کنید. به طور مشابه، آزمایش شما باید از افزودن یا حذف اطلاعات تماس واقعی در یک ارائه دهنده اجتناب کند.
برای آزمایش ارائه دهنده محتوای خود به صورت مجزا، از کلاس ProviderTestCase2 استفاده کنید. این کلاس به شما امکان می دهد از کلاس های شیء ساختگی اندروید مانند IsolatedContext و MockContentResolver برای دسترسی به اطلاعات فایل و پایگاه داده بدون تأثیر بر داده های واقعی کاربر استفاده کنید.
آزمون ادغام شما باید به عنوان یک کلاس تست JUnit 4 نوشته شود. برای کسب اطلاعات بیشتر در مورد ایجاد کلاس‌های آزمایشی JUnit 4 و استفاده از اظهارات JUnit 4، به ایجاد کلاس تست واحد محلی مراجعه کنید.
برای ایجاد یک تست یکپارچه سازی برای ارائه دهنده محتوای خود، باید این مراحل را انجام دهید:
- کلاس آزمایشی خود را به عنوان زیر کلاس
ProviderTestCase2 ایجاد کنید. - کلاس
AndroidJUnitRunner را که AndroidX Test به عنوان اجرای آزمایشی پیش‌فرض شما ارائه می‌کند، مشخص کنید. - شی
Context را از کلاس ApplicationProvider تنظیم کنید. برای نمونه به قطعه زیر مراجعه کنید.
کاتلین
@Throws(Exception::class)
override fun setUp() {
super.setUp()
context = ApplicationProvider.getApplicationContext<Context>()
} جاوا
@Override
protected void setUp() throws Exception {
super.setUp();
setContext(ApplicationProvider.getApplicationContext());
} نحوه عملکرد ProviderTestCase2
شما ارائه دهنده ای را با زیر کلاس ProviderTestCase2 آزمایش می کنید. این کلاس پایه AndroidTestCase را گسترش می‌دهد، بنابراین چارچوب تست JUnit و همچنین روش‌های خاص اندروید را برای آزمایش مجوزهای برنامه ارائه می‌کند. مهمترین ویژگی این کلاس مقدار دهی اولیه آن است که محیط تست ایزوله را ایجاد می کند.
مقداردهی اولیه
مقداردهی اولیه در سازنده ProviderTestCase2 انجام می شود که زیر کلاس ها سازنده های خود را فراخوانی می کنند. سازنده ProviderTestCase2 یک شی IsolatedContext ایجاد می کند که به عملیات فایل و پایگاه داده اجازه می دهد اما سایر تعاملات با سیستم Android را حذف می کند. خود عملیات فایل و پایگاه داده در یک دایرکتوری انجام می شود که محلی برای دستگاه یا شبیه ساز است و دارای یک پیشوند خاص است.
سازنده سپس یک MockContentResolver ایجاد می کند تا از آن به عنوان حل کننده برای آزمایش استفاده کند.
در نهایت، سازنده نمونه ای از ارائه دهنده تحت آزمایش ایجاد می کند. این یک شی ContentProvider معمولی است، اما تمام اطلاعات محیط خود را از IsolatedContext می گیرد، بنابراین به کار در محیط آزمایش ایزوله محدود می شود. تمام تست های انجام شده در کلاس test case بر روی این شی ایزوله اجرا می شود.
شما تست‌های یکپارچه‌سازی را برای ارائه‌دهندگان محتوا به همان روشی که تست‌های واحد ابزاردار اجرا می‌کنید، اجرا می‌کنید.
چه چیزی را تست کنیم
در اینجا چند دستورالعمل خاص برای آزمایش ارائه دهندگان محتوا آورده شده است.
- تست با روش‌های حل‌کننده : حتی اگر می‌توانید یک شی ارائه‌دهنده را در
ProviderTestCase2 نمونه‌سازی کنید، همیشه باید با استفاده از URI مناسب، با یک شیی حل‌کننده آزمایش کنید. انجام این کار تضمین می کند که با انجام همان تعاملی که یک برنامه معمولی از آن استفاده می کند، ارائه دهنده را آزمایش می کنید. - آزمایش یک ارائه‌دهنده عمومی به‌عنوان قرارداد : اگر می‌خواهید ارائه‌دهنده شما عمومی و در دسترس سایر برنامه‌ها باشد، باید آن را به عنوان قرارداد آزمایش کنید. چند نمونه از نحوه انجام این کار به شرح زیر است:
- با ثابت هایی که ارائه دهنده شما به طور عمومی افشا می کند آزمایش کنید. به عنوان مثال، به دنبال ثابت هایی بگردید که به نام ستون ها در یکی از جداول داده های ارائه دهنده اشاره می کنند. اینها همیشه باید ثابت هایی باشند که به صورت عمومی توسط ارائه دهنده تعریف شده اند.
- تمام URI هایی را که ارائه دهنده شما ارائه می دهد آزمایش کنید. ارائه دهنده شما ممکن است چندین URI ارائه دهد که هر یک به جنبه متفاوتی از داده ها اشاره دارد.
- URI های نامعتبر را آزمایش کنید. آزمایش‌های واحد شما باید عمداً با ارائه‌دهنده‌ای با URI نامعتبر تماس بگیرد و به دنبال خطا باشد. یک طراحی ارائه دهنده خوب این است که یک
IllegalArgumentException برای URI های نامعتبر ایجاد کند.
- تعاملات ارائه دهنده استاندارد را آزمایش کنید : اکثر ارائه دهندگان شش روش دسترسی را ارائه می دهند:
query() , insert() , delete() , update() , getType() و onCreate() . آزمایش‌های شما باید تأیید کنند که همه این روش‌ها کار می‌کنند. - تست منطق کسب و کار : اگر ارائه دهنده محتوا منطق کسب و کار را پیاده سازی می کند، باید آن را آزمایش کنید. منطق تجاری شامل مدیریت مقادیر نامعتبر، محاسبات مالی یا حسابی، حذف یا ترکیب موارد تکراری است.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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."]]
