الاختبار في "استوديو Android" اشرح الاختبار من سطر الأوامر كيفية ضبط تهيئة وتشغيل تهيئات الاختبار الأساسية. ومع ذلك، عندما يتم تثبيت التطبيق متطلبات الاختبار أكثر تقدمًا، فقد تحتاج إلى تكييف الاختبار المزيد من التكوينات. على سبيل المثال، قد تحتاج إلى إعداد اختبار متقدم عند عليك إجراء ما يلي:
- إجراء اختبارات قياس حالة التطبيق لخيار إصدار معيّن فقط أو إلغاء ذلك إعدادات البيان.
- تغيير نوع التصميم الذي يتم إجراء الاختبارات عليه أو ضبط Gradle الخيارات.
- استخرِج اختبارات الأدوات من وحدة الاختبار الخاصة بها.
- يمكنك إجراء اختبارات أكثر تقدّمًا كجزء من عملية إعداد ميزة "الدمج المستمر".
توضّح هذه الصفحة طرقًا مختلفة لضبط إعدادات اختباراتك عندما تكون لا تتناسب مع احتياجاتك.
إنشاء اختبار قياسي لصيغة الإصدار
إذا كان مشروعك يتضمّن إصدارات إصدار باستخدام مجموعات مصادر فريدة، يمكنك تضمين اختبارات آلية مع مجموعات المصادر هذه. وهذا يحافظ على رمز الاختبار منظمًا يتيح لك إجراء الاختبارات التي تنطبق على صيغة إصدار معيّنة فقط.
لربط الاختبارات المُعدَّة بنُسخة مختلفة من التطبيق، ضَعها في نتائج البحث الخاصة بها.
مجموعة المصدر، وتقع في
src/androidTestVariantName
يشارك الجميع الاختبارات التي يتم قياسها في مجموعة المصادر src/androidTest/
متغيرات التصميم. عند إنشاء حِزمة APK تجريبية لـ "MyFlapor" صيغة
Gradle، وهي تجمع بين src/androidTest/
وsrc/androidTestMyFlavor/
مجموعات المصادر.
لإضافة مجموعة مصادر اختبار لصيغة الإصدار في "استوديو Android"، يُرجى اتّباع الخطوات التالية: الخطوات التالية:
- في نافذة المشروع، انقر على القائمة واختَر عرض المشروع.
- ضمن مجلد الوحدة المناسب، انقر بزر الماوس الأيمن على مجلد src انقر على جديد > الدليل.
- بالنسبة إلى اسم الدليل، أدخِل "androidTestVariantName". على سبيل المثال، إذا
لديك نسخة إصدار تسمى "MyFLAor"، استخدام اسم الدليل
androidTestMyFlavor
- انقر على موافق.
- انقر بزر الماوس الأيمن على الدليل الجديد واختر جديد > الدليل.
- أدخل "java" كاسم للدليل، ثم انقر على حسنًا.
يمكنك الآن إضافة اختبارات إلى هذا المصدر الجديد من خلال اتّباع خطوات إضافة اختبار جديد. عندما تصل إلى مربع الحوار اختيار دليل الوجهة، حدد الدليل الجديد مجموعة مصدر اختبار الصيغة.
يوضح الجدول التالي مثالاً على كيفية احتمال ظهور ملفات اختبار الأدوات متوفّرة في مجموعات المصادر التي تتوافق مع مجموعات مصادر الرموز البرمجية للتطبيق:
المسار إلى فئة التطبيق | مسار فئة اختبار قياس حالة التطبيق |
---|---|
src/main/java/Example.java
|
src/androidTest/java/AndroidExampleTest.java
|
src/myFlavor/java/Example.java
|
src/androidTestMyFlavor/java/AndroidExampleTest.java
|
وكما هو الحال مع مجموعات مصادر التطبيقات، يتم دمج إصدار Gradle
تلغي الملفات من مجموعات مصادر الاختبار المختلفة. في هذه الحالة،
عدد الملفات التي تم إلغاؤها في مجموعة المصادر androidTestMyFlavor
: AndroidExampleTest.java
الإصدار في مجموعة مصادر androidTest
. هذا بسبب
تكون لمجموعة مصدر نكهة المنتج الأولوية على مجموعة المصدر الرئيسية.
عند اختيار نكهات مختلفة في أداة اختيار صيغ التصميم،
يتم عرض مجلدات androidTest
المناسبة في طريقة عرض Android
إظهار المجلدات المستخدمة:
لا يظهر المجلد "androidTestMyFlavor
" عند عرض خيار آخر.
تم تحديد:
يبدو هذا مختلفًا بعض الشيء إذا كنت تستخدم طريقة عرض المشروع، ولكنك المبدأ:
عند تحديد خيار مختلف، يبقى المجلد "androidTestMyFlavor
"
مرئية، ولكن لا تظهر كنشطة:
لمزيد من المعلومات عن كيفية دمج مجموعات المصادر، راجِع المقالة مجموعات المصادر:
ضبط إعدادات بيان قياس حالة التطبيق
الاختبارات التي يتم قياسها مُدمَجة في حِزمة APK منفصلة ومزوَّدة بخصائصها الخاصة
ملف AndroidManifest.xml
. وعندما تنشئ Gradle ملف APK التجريبي، فإنه
ملف AndroidManifest.xml
تلقائيًا وإعداده
مع
عقدة <instrumentation>
.
أحد أسباب تهيئة Gradle لك لهذه العقدة هو التأكد من
targetPackage
الخاصية اسم حزمة التطبيق الصحيح قيد الاختبار.
لتغيير إعدادات أخرى لهذه العقدة، يمكنك إنشاء إما
ملف بيان في مجموعة مصادر الاختبار أو قم بتهيئة مستوى الوحدة
ملف واحد (build.gradle
)، كما هو موضّح في
عينة التعليمة البرمجية التالية. يمكن العثور على القائمة الكاملة بالخيارات في
BaseFlavor
مرجع واجهة برمجة التطبيقات.
Groovy
android { ... defaultConfig { ... testApplicationId "com.example.test" testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner" testHandleProfiling true testFunctionalTest true } }
Kotlin
android { ... defaultConfig { ... testApplicationId = "com.example.test" testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner" testHandleProfiling = true testFunctionalTest = true } }
Each product flavor you configure can override properties in the
defaultConfig {}
block. To learn more, go to Configure product
flavors.
The properties in the snippet are:
Setting | Description |
---|---|
testApplicationId
|
Specifies the application ID for the test APK. |
testInstrumentationRunner
|
Specifies the fully qualified class name of the test instrumentation runner. |
testHandleProfiling
|
If set to true , enables the instrumentation class
to start and stop profiling.If set to false , profiling occurs the entire time
the instrumentation class is running. |
testFunctionalTest
|
If set to true , indicates that the Android system
should run the instrumentation class as a functional
test.The default value is false . |
Change the test build type
By default, all instrumentation tests run against the debug
build type.
You can change this to another build type by using the testBuildType
property in your module-level build.gradle
file. For example, if you want
to run your tests against your staging
build type, edit the file as
shown in the following snippet:
Groovy
android { ... testBuildType "staging" }
Kotlin
android { ... testBuildType = "staging" }
ضبط خيارات اختبار Gradle
يتيح لك المكوّن الإضافي لنظام Gradle المتوافق مع Android
تحديد خيارات معينة لجميع الاختبارات أو لبعضها فقط. في جلسة المعمل،
build.gradle
على مستوى الوحدة، استخدم
testOptions
منعها لتحديد الخيارات التي تغيّر طريقة تشغيل Gradle لجميع الاختبارات:
Groovy
android { ... // Encapsulates options for running tests. testOptions { reportDir "$rootDir/test-reports" resultsDir "$rootDir/test-results" } }
Kotlin
android { ... // Encapsulates options for running tests. testOptions { reportDir "$rootDir/test-reports" resultsDir = "$rootDir/test-results" } }
تغيّر السمة reportDir
الدليل الذي تحفظ فيه Gradle الاختبار.
التقارير. تحفظ Gradle تلقائيًا تقارير الاختبار في
دليل path_to_your_project/module_name
/build/outputs/reports/
. يحدد $rootDir
المسار نسبيًا
إلى الدليل الجذري للمشروع الحالي.
تغيّر السمة resultsDir
الدليل الذي تحفظ فيه Gradle الاختبار.
نتائجك. تحفظ Gradle نتائج الاختبار تلقائيًا في
دليل path_to_your_project/module_name
/build/outputs/test-results/
. يحدد $rootDir
المسار نسبيًا
إلى الدليل الجذري للمشروع الحالي.
لتحديد خيارات لاختبارات الوحدة المحلية فقط، اضبط
unitTests
حظر داخل testOptions
Groovy
android { ... testOptions { ... // Encapsulates options for local unit tests. unitTests { returnDefaultValues true all { jvmArgs '-XX:MaxPermSize=256m' if (it.name == 'testDebugUnitTest') { systemProperty 'debug', 'true' } ... } } } }
Kotlin
android { ... testOptions { ... // Encapsulates options for local unit tests. unitTests { returnDefaultValues = true all { jvmArgs = listOf("-XX:MaxPermSize=256m") if (it.name == "testDebugUnitTest") { systemProperty = mapOf("debug" to "true") } ... } } } }
بشكلٍ تلقائي، تُستثنى اختبارات الوحدات المحلية من الحالات التي يتم فيها إرسال الرمز
تحاول الوصول إلى واجهات برمجة تطبيقات النظام الأساسي لنظام التشغيل Android، ما لم
محاكاة لتبعيات Android
بنفسك أو باستخدام إطار عمل اختبار مثل
النموذج التجريبي مع ذلك، يمكنك تفعيل السمة returnDefaultValues
لكي يكون
يعرض الاختبار القيمة "صفر" أو "صفر" عند الوصول إلى واجهات برمجة التطبيقات للنظام الأساسي،
من طرح استثناء.
تضم كتلة all
خيارات للتحكم في كيفية تنفيذ Gradle
اختبارات الوحدة المحلية. للحصول على قائمة بجميع الخيارات التي يمكنك تحديدها، اقرأ
مستندات Gradle المرجعية
تضبط السمة jvmArgs
وسيطات JVM لاختبارات JVM.
يمكنك أيضًا التحقّق من اسم المهمة لتطبيق الخيارات على الاختبارات التي
التحديد. في مثال المقتطف، يتم ضبط السمة debug
على true
، ولكن
فقط لمهمة testDebugUnitTest
.
استخدام وحدات اختبار منفصلة للاختبارات الموجَّهة
إذا كنت ترغب في الحصول على وحدة مخصصة لاختبارات الأجهزة، لعزل باقي التعليمات البرمجية من اختباراتك، وإنشاء وحدة اختبار منفصلة تكوين بنيته بطريقة مماثلة لتلك الخاصة بوحدة المكتبة.
لإنشاء وحدة اختبار، اتّبِع الخطوات التالية:
- أنشئ وحدة مكتبة.
- في ملف
build.gradle
على مستوى الوحدة، طبِّقcom.android.test
. المكون الإضافي بدلاً منcom.android.library
. - انقر على مزامنة المشروع .
بعد إنشاء وحدة الاختبار، يمكنك تضمين كود الاختبار في
المصدر الرئيسي أو المتغير (على سبيل المثال، src/main/java
أو
src/variant/java
). إذا كانت وحدة التطبيق تحدِّد
نكهات منتج متعددة، يمكنك إعادة إنشاء تلك النكهات في وحدة الاختبار الخاصة بك.
استخدام التبعية الواعية للمتغير
الإدارة أو
تحاول وحدة الاختبار اختبار النكهة المطابقة في الوحدة المستهدفة.
تتضمّن وحدات الاختبار صيغة تصحيح أخطاء فقط وتختبرها تلقائيًا. ومع ذلك،
يمكنك إنشاء أنواع إنشاءات جديدة
لتناسب مشروع التطبيقات الذي تم اختباره. لإجراء
وحدة اختبار نوع تصميم مختلف وليس نوع تصحيح الأخطاء، استخدم
VariantFilter
لإيقاف صيغة تصحيح الأخطاء في المشروع التجريبي، كما هو موضّح:
Groovy
android { variantFilter { variant -> if (variant.buildType.name.equals('debug')) { variant.setIgnore(true); } } }
Kotlin
android { variantFilter { if (buildType.name == "debug") { ignore = true } } }
إذا كنت تريد وحدة اختبار لاستهداف نكهات معينة فقط أو إنشاء أنواع من
التطبيق، يمكنك استخدام matchingFallbacks
لاستهداف الصيغ التي تريد اختبارها فقط. وهذا يمنع أيضًا
وحدة اختبار من الحاجة إلى إعداد تلك المتغيرات بنفسها.