בודקים ב-Android Studio ו בדיקה משורת הפקודה שמסבירה איך להגדיר ונריץ תצורות בדיקה בסיסיות. עם זאת, כשהאפליקציה תשתפרו את דרישות הבדיקה, אולי תצטרכו להתאים את הבדיקה הגדרות נוספות. לדוגמה, יכול להיות שתצטרכו להגדיר בדיקה מתקדמת לבצע את הפעולות הבאות:
- להריץ בדיקות אינסטרומנטטיביות רק לווריאנט build ספציפי או לבטל את הגדרות המניפסט.
- שינוי סוג ה-build שהבדיקות פועלות מולו או הגדרה של Gradle אפשרויות.
- מחלצים את הבדיקות האינסטרומנטטיביות למודול בדיקה משלהם.
- מבצעים בדיקות מתקדמות יותר כחלק מהגדרת השילוב הרציף.
בדף הזה מתוארות דרכים שונות להגדרת הבדיקות כאשר ברירת המחדל ההגדרות לא מתאימות לצרכים שלכם.
יצירת בדיקה של אינסטרומנטציה לווריאנט build
אם הפרויקט כולל גרסאות build עם קבוצות מקור ייחודיות, ייתכן שתרצו לכלול בדיקות אינסטרומנטליות שתואמים לקבוצות המקור האלה. כך קוד הבדיקה שלך מאורגן מאפשרת להריץ רק את הבדיקות שרלוונטיות לווריאנט נתון של build.
כדי לקשר בדיקות מכוסות לווריאנט של build, יש למקם אותן בו-זמנית
קבוצת המקור, שנמצאת ב-
src/androidTestVariantName
בדיקות אינסטרומנטטיביות בקבוצת המקור src/androidTest/
משותפות לכולם
ליצור וריאציות. כשיוצרים חבילת APK לבדיקה בשביל MyFlavor של
app, Gradle משלבת את src/androidTest/
ו-src/androidTestMyFlavor/
בקבוצות המקור.
כדי להוסיף ב-Android Studio קבוצת מקור לבדיקה לווריאנט ה-build שלך, פועלים לפי השלבים הבאים: את השלבים הבאים:
- בחלון Project, לוחצים על התפריט ובוחרים בתצוגה Project.
- בתיקיית המודול המתאימה, לוחצים לחיצה ימנית על תיקיית src ואז לוחצים על חדש > Google Directory.
- בשדה של שם הספרייה, מזינים androidTestVariantName. לדוגמה, אם
יש לכם גרסת build שנקראת MyFlavor, שימוש בשם הספרייה
androidTestMyFlavor
- לוחצים על אישור.
- לוחצים לחיצה ימנית על הספרייה החדשה ובוחרים באפשרות New > Google Directory.
- מזינים 'Java' בתור שם הספרייה, ואז לוחצים על OK.
עכשיו אפשר להוסיף בדיקות למקור החדש שהוגדר באופן הבא: השלבים להוספת בדיקה חדשה. כשמגיעים לתיבת הדו-שיח בחירת ספריית יעדים, בוחרים את תיבת הדו-שיח החדשה הוגדר מקור לבדיקת הווריאנט.
הטבלה הבאה מציגה דוגמה לאופן שבו קובצי בדיקת אינסטרומנטציה יכולים נמצאות בקבוצות מקור שתואמות לקבוצות הקוד של האפליקציה:
טבלה 1. קוד המקור של האפליקציה ואפליקציות קבצים של בדיקת אינסטרומנטציה
נתיב לכיתה של אפליקציה | נתיב למחלקה תואמת של בדיקת אינסטרומנטציה |
---|---|
src/main/java/Example.java
|
src/androidTest/java/AndroidExampleTest.java
|
src/myFlavor/java/Example.java
|
src/androidTestMyFlavor/java/AndroidExampleTest.java
|
בדיוק כמו במקרה של קבוצות מקורות של אפליקציות, תהליך מיזוג ה-build של Gradle
מבטל קבצים מקבוצות מקור שונות של בדיקות. במקרה הזה, הפרמטר
קובץ AndroidExampleTest.java
בברירת המחדל של קבוצת המקור androidTestMyFlavor
הגרסה בקבוצת המקור androidTest
. הסיבה לכך היא
לקבוצת המקור בטעם המוצר יש עדיפות על פני קבוצת המקור הראשי.
כשבוחרים בטעמים שונים בבורר וריאציות ה-build,
androidTest
התיקיות המתאימות מוצגות בתצוגת Android כדי
הצגת התיקיות שבהן נעשה שימוש:
![הווריאנט MyFlavor נבחר והתיקייה androidTestMyFlavor מוצגת
בתצוגת Android](https://developer.android.com/static/studio/images/test/test-myflavor-android-test-android-view.png?authuser=0000&hl=he)
MyFlavor
); ה
התיקייה androidTestMyFlavor
מוצגת בתצוגת Android.התיקייה androidTestMyFlavor
לא מוצגת כשיש וריאנט אחר
נבחר:
![נבחרה וריאנט otherFlavor, והתיקייה androidTestMyFlavor לא
מוצגת בתצוגת Android](https://developer.android.com/static/studio/images/test/test-otherflavor-android-test-android-view.png?authuser=0000&hl=he)
OtherFlavor
); ה
התיקייה androidTestMyFlavor
לא מופיעה בתצוגת Android.התצוגה הזו נראית קצת שונה אם משתמשים בתצוגה Project, אבל אותה תצוגה העיקרון חל:
![נבחרה וריאנט MyFlavor והתיקייה androidTestMyFlavor פעילה
בתצוגת פרויקט](https://developer.android.com/static/studio/images/test/test-myflavor-android-test-project-view.png?authuser=0000&hl=he)
MyFlavor
); ה
התיקייה androidTestMyFlavor
פעילה בתצוגה Project.אם בוחרים וריאנט אחר, התיקייה androidTestMyFlavor
עדיין נשארת
גלוי, אבל לא מופיע כפעיל:
![נבחרה וריאנט otherFlavor, והתיקייה androidTestMyFlavor לא
פעיל בתצוגת פרויקט](https://developer.android.com/static/studio/images/test/test-otherflavor-android-test-project-view.png?authuser=0000&hl=he)
OtherFlavor
); ה
התיקייה androidTestMyFlavor
לא פעילה בתצוגה Project.למידע נוסף על אופן המיזוג של קבוצות מקורות, אפשר לעיין במאמר קבוצות מקורות.
קביעת הגדרות מניפסט של אינסטרומנטציה
בדיקות אינסטרומנטליות מובְנות ב-APK נפרד עם משלו
קובץ AndroidManifest.xml
. כש-Gradle יוצר את חבילת ה-APK לבדיקה,
יוצר את הקובץ AndroidManifest.xml
ומגדיר אותו באופן אוטומטי
עם
צומת <instrumentation>
.
אחת הסיבות ש-Gradle מגדיר את הצומת הזה עבורכם היא לוודא
targetPackage
מציין את שם החבילה הנכון של האפליקציה בבדיקה.
כדי לשנות הגדרות אחרות לצומת הזה, צריך ליצור צומת אחר
קובץ מניפסט בקבוצת מקור הבדיקה או הגדרה ברמת המודול
קובץ build.gradle
, כפי שמוצג
את דוגמת הקוד הבאה. רשימת האפשרויות המלאה מופיעה בקטע
BaseFlavor
הפניית API.
מגניב
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
הפלאגין Android Gradle מאפשר לך
להגדיר אפשרויות מסוימות לכל הבדיקות או רק לחלק מהן. ב
build.gradle
ברמת המודול, משתמשים
testOptions
כדי לציין אפשרויות שישנו את האופן שבו Gradle תריץ את כל הבדיקות:
מגניב
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
.
מגניב
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") } ... } } } }
כברירת מחדל, בדיקות יחידה מקומיות גורמות לחריגה בכל פעם שהקוד
שאתם בודקים מנסים לגשת לממשקי API של פלטפורמת Android, אלא אם
לדמות יחסי תלות של Android
לבד או במסגרת בדיקה,
מוקיטו. עם זאת, אפשר להפעיל את הנכס returnDefaultValues
כדי
הבדיקה מחזירה ערך של null או אפס כאשר ניגשים לממשקי ה-API של הפלטפורמה,
מאשר לבטל את החריגה.
הבלוק all
כולל אפשרויות לשליטה באופן ההפעלה של Gradle
בדיקות יחידות מקומיות. לרשימה של כל האפשרויות שניתן להגדיר, אפשר לקרוא
מאמרי העזרה של Gradle.
המאפיין jvmArgs
מגדיר ארגומנטים של JVM ל-JVM לבדיקה.
אפשר גם לבדוק את שם המשימה כדי להחיל אפשרויות רק על הבדיקות
להגדיר. בקטע הקוד לדוגמה, הנכס debug
מוגדר כ-true
, אבל
רק למשימה testDebugUnitTest
.
להשתמש במודולים נפרדים לבדיקה עבור בדיקות אינסטרומנטליות
אם רוצים ליצור מודול ייעודי לבדיקות אינסטרומנטליות, כדי לבודד את את שאר הקוד מהבדיקות, צרו מודול בדיקה נפרד להגדיר את ה-build שלו באופן דומה לזה של מודול ספרייה.
כדי ליצור מודול בדיקה, מבצעים את הפעולות הבאות:
- יוצרים מודול של ספרייה.
- בקובץ
build.gradle
ברמת המודול, מחילים את ה-com.android.test
במקוםcom.android.library
. - לוחצים על Sync Project (סנכרון פרויקט)
.
אחרי שיוצרים את מודול הבדיקה, אפשר לכלול את קוד הבדיקה בקטע
קבוצת מקור ראשית או וריאנט (לדוגמה, src/main/java
או
src/variant/java
). אם מודול האפליקציה
טעמים שונים של מוצרים, תוכלו ליצור מחדש את הטעמים האלה במודול הבדיקה.
שימוש בתלות תוך התייחסות למשתנים
management,
מודול הבדיקה מנסה לבדוק את הטעם התואם במודול היעד.
כברירת מחדל, מודולים לבדיקה מכילים ובודקים רק וריאנט של ניפוי באגים. אבל, לפעמים
אפשר ליצור סוגי build חדשים שיתאימו לפרויקט האפליקציה שנבדק. כדי להפוך את
לבדיקת מודול הבדיקה סוג build אחר ולא של ניפוי הבאגים, השתמשו
VariantFilter
כדי להשבית את הווריאנט של ניפוי הבאגים בפרויקט הבדיקה, כפי שמוצג בדוגמה הבאה:
מגניב
android { variantFilter { variant -> if (variant.buildType.name.equals('debug')) { variant.setIgnore(true); } } }
Kotlin
android { variantFilter { if (buildType.name == "debug") { ignore = true } } }
אם רוצים שמודול בדיקה יטרגט רק טעמים מסוימים או סוגי build מסוימים
האפליקציה, אפשר להשתמש בmatchingFallbacks
כדי לטרגט רק את הווריאנטים שרוצים לבדוק. הפעולה הזו מונעת גם
כי הוא לא צריך להגדיר את הווריאציות האלה בעצמו.