הגדרת בדיקה מתקדמת

במאמרים בדיקה ב-Android Studio ובדיקה משורת הפקודה מוסבר איך להגדיר ולהריץ תצורות בדיקה בסיסיות. עם זאת, כשהאפליקציה והדרישות לבדיקה שלה מתקדמות יותר, יכול להיות שתצטרכו להתאים עוד יותר את הגדרות הבדיקה. לדוגמה, יכול להיות שתצטרכו הגדרת בדיקה מתקדמת אם תרצו:

  • להריץ בדיקות עם מכשור רק עבור וריאנט build ספציפי או לבטל את הגדרות המניפסט שלה.
  • משנים את סוג ה-build שהבדיקות מורצות מולו או מגדירים את האפשרויות של Gradle.
  • מחלקים את הבדיקות עם המכשיר למודול בדיקה משלהן.
  • אפשר לבצע בדיקות מתקדמות יותר כחלק מההגדרה של שילוב מתמשך.

בדף הזה מתוארות כמה דרכים להגדיר את הבדיקות כשברירת המחדל לא מתאימה לצרכים שלכם.

יצירת בדיקה עם מכשור לוריאנט build

אם הפרויקט שלכם כולל וריאציות של build עם קבוצות מקור ייחודיות, כדאי לכלול בדיקות עם מכשור שמתאימות לקבוצות המקור האלה. כך קוד הבדיקה נשאר מאורגן ואפשר להריץ רק את הבדיקות שרלוונטיות לווריאנט build מסוים.

כדי לקשר בדיקות עם מכשור לוריאנט build, צריך למקם אותן בקבוצת מקורות משלהן, שנמצאת ב-src/androidTestVariantName.

בדיקות עם מכשור בקבוצת המקורות src/androidTest/ משותפות לכל וריאנט build. כשיוצרים קובץ APK לבדיקה של הווריאנט MyFlavor באפליקציה, Gradle משלב את קבוצות המקור src/androidTest/ ו-src/androidTestMyFlavor/.

כדי להוסיף קבוצת מקורות לבדיקות עבור וריאנט build ב-Android Studio, פועלים לפי השלבים הבאים:

  1. בחלון Project (פרויקט), לוחצים על התפריט ובוחרים בתצוגה Project (פרויקט).
  2. בתיקיית המודול המתאימה, לוחצים לחיצה ימנית על התיקייה src ולוחצים על New > Directory (חדש > ספרייה).
  3. בשם הספרייה, מזינים 'androidTestVariantName'. לדוגמה, אם יש לכם וריאנט build בשם MyFlavor, צריך להשתמש בשם התיקייה androidTestMyFlavor.
  4. לוחצים על אישור.
  5. לוחצים לחיצה ימנית על הספרייה החדשה ובוחרים באפשרות חדש > ספרייה.
  6. מזינים java בתור שם הספרייה ולוחצים על אישור.

עכשיו אפשר להוסיף בדיקות לקבוצת המקורות החדשה הזו. כדי לעשות זאת, פועלים לפי השלבים להוספת בדיקה חדשה. כשמגיעים לתיבת הדו-שיח בחירת ספריית יעד, בוחרים את קבוצת המקור החדשה של בדיקת הווריאציות.

בטבלה הבאה מוצגת דוגמה לאופן שבו קובצי בדיקות אינסטרומנטציה יכולים להיות ממוקמים בערכות מקור שתואמות לערכות מקור של קוד האפליקציה:

טבלה 1. קוד המקור של האפליקציה וקבצי בדיקות האינסטרומנטציה התואמים

הנתיב למחלקה של האפליקציה הנתיב למחלקה תואמת של בדיקת אינסטרומנטציה
src/main/kotlin+java/Example.kt src/androidTest/java/AndroidExampleTest.kt
src/myFlavor/kotlin+java/Example.kt src/androidTestMyFlavor/java/AndroidExampleTest.kt

בדיוק כמו במקרה של קבוצות המקור של האפליקציה, קובץ ה-build של Gradle ממזג ומחליף קבצים מקבוצות מקור שונות של בדיקות. במקרה כזה, הקובץ AndroidExampleTest.kt בקבוצת המקורות androidTestMyFlavor מבטל את הגרסה בקבוצת המקורות androidTest. הסיבה לכך היא שקבוצת המקורות של גרסת המוצר מקבלת עדיפות על פני קבוצת המקורות הראשית.

כשבוחרים וריאנטים שונים של build בתפריט הבחירה, התיקיות המתאימות של androidTest מוצגות בתצוגה Android כדי להראות את התיקיות שנעשה בהן שימוש:

הגרסה MyFlavor נבחרה והתיקייה androidTestMyFlavor מוצגת בתצוגת Android
איור 1. ‫MyFlavor variant selected; the androidTestMyFlavor folder displays in the Android view.

התיקייה androidTestMyFlavor לא מוצגת כשבוחרים וריאציה אחרת:

נבחרה וריאציה מסוג OtherFlavor והתיקייה androidTestMyFlavor לא מוצגת בתצוגת Android
איור 2. ‫OtherFlavor נבחרה גרסה; התיקייה androidTestMyFlavor לא מוצגת בתצוגה של Android.

אם אתם משתמשים בתצוגה Project, התצוגה תהיה קצת שונה, אבל העיקרון זהה:

הווריאציה MyFlavor נבחרה והתיקייה androidTestMyFlavor פעילה בתצוגת הפרויקט
איור 3. MyFlavor הגרסה שנבחרה; התיקייה androidTestMyFlavor פעילה בתצוגה Project.

כשבוחרים וריאציה אחרת, התיקייה androidTestMyFlavor עדיין גלויה, אבל היא לא מוצגת כפעילה:

המשתנה OtherFlavor נבחר והתיקייה androidTestMyFlavor לא פעילה בתצוגת הפרויקט
איור 4. ‫OtherFlavor variant selected; the androidTestMyFlavor folder is not active in the Project view.

מידע נוסף על אופן המיזוג של קבוצות מקורות זמין במאמר בנושא קבוצות מקורות.

הגדרת מניפסט של מכשור

בדיקות עם מכשור מובנות בקובץ APK נפרד עם קובץ AndroidManifest.xml משלו. כש-Gradle יוצר את ה-APK של הבדיקה, הוא יוצר באופן אוטומטי את הקובץ AndroidManifest.xml ומגדיר אותו באמצעות הצומת <instrumentation>. אחת הסיבות לכך ש-Gradle מגדיר את הצומת הזה בשבילכם היא לוודא שהמאפיין targetPackage מציין את שם החבילה הנכון של האפליקציה שנבדקת.

כדי לשנות הגדרות אחרות של הצומת הזה, אפשר ליצור קובץ מניפסט נוסף בערכת המקור של הבדיקה או להגדיר את קובץ build.gradle ברמת המודול, כמו בדוגמת הקוד הבאה. הרשימה המלאה של האפשרויות זמינה בBaseFlavorהפניה ל-API.

Kotlin

android {
    ...
    defaultConfig {
        ...
        testApplicationId = "com.example.test"
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling = true
        testFunctionalTest = true
    }
}

מגניב

android {
    ...
    defaultConfig {
        ...
        testApplicationId "com.example.test"
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling true
        testFunctionalTest true
    }
}

כל גרסת מוצר שאתם מגדירים יכולה לבטל מאפיינים בבלוק defaultConfig {}. מידע נוסף זמין במאמר הגדרת טעמים של מוצרים.

המאפיינים בקטע הקוד הם:

הגדרה תיאור
testApplicationId מציין את מזהה האפליקציה של ה-APK לבדיקה.
testInstrumentationRunner מציינת את השם המלא של המחלקה של כלי ההרצה של בדיקת המכשיר.
testHandleProfiling אם ההגדרה היא true, מופעלת מחלקת המדידה כדי להתחיל ולסיים את יצירת הפרופיל.
אם המדיניות מוגדרת כ-false, יתבצע פרופיל כל הזמן שמחלקת המכשור פועלת.
testFunctionalTest אם הערך הוא true, המערכת של Android מריצה את מחלקת המכשור כבדיקה פונקציונלית.
ערך ברירת המחדל הוא false.

שינוי סוג גרסת הבדיקה

כברירת מחדל, כל בדיקות המכשור מופעלות מול debug סוג ה-build. אפשר לשנות את זה לסוג build אחר באמצעות המאפיין testBuildType בקובץ build.gradle ברמת המודול. לדוגמה, אם רוצים להריץ את הבדיקות מול staging סוג ה-build, צריך לערוך את הקובץ כמו שמוצג בקטע הקוד הבא:

Kotlin

android {
    ...
    testBuildType = "staging"
}

מגניב

android {
    ...
    testBuildType "staging"
}

הגדרת אפשרויות בדיקה ב-Gradle

הפלאגין של Android Gradle מאפשר לכם לציין אפשרויות מסוימות לכל הבדיקות או רק לחלק מהן. בקובץ build.gradle ברמת המודול, משתמשים בבלוק testOptions כדי לציין אפשרויות שמשנות את האופן שבו Gradle מריץ את כל הבדיקות:

Kotlin

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        reportDir = "$rootDir/test-reports"
        resultsDir = "$rootDir/test-results"
    }
}

מגניב

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.

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 {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            returnDefaultValues true

            all {
                jvmArgs '-XX:MaxPermSize=256m'

                if (it.name == 'testDebugUnitTest') {
                    systemProperty 'debug', 'true'
                }
                ...
            }
        }
    }
}

כברירת מחדל, בדיקות יחידה מקומיות יוצרות חריגה בכל פעם שהקוד שאתם בודקים מנסה לגשת לממשקי API של פלטפורמת Android, אלא אם מדמים תלות ב-Android בעצמכם או באמצעות מסגרת בדיקה כמו Mockito. עם זאת, אפשר להפעיל את המאפיין returnDefaultValues כדי שהבדיקה תחזיר null או אפס כשניגשים לממשקי API של הפלטפורמה, במקום להחזיר חריגה.

הבלוק all כולל אפשרויות לשליטה באופן שבו Gradle מריץ בדיקות יחידה מקומיות. רשימה של כל האפשרויות שאפשר לציין מופיעה במאמרי העזרה של Gradle.

המאפיין jvmArgs מגדיר ארגומנטים של JVM עבור מכונות ה-JVM של הבדיקה.

אפשר גם לבדוק את שם המשימה כדי להחיל אפשרויות רק על הבדיקות שצוינו. בדוגמה לקטע הקוד, המאפיין debug מוגדר ל-true, אבל רק למשימה testDebugUnitTest.

שימוש במודולים נפרדים לבדיקות עם מכשור

אם רוצים ליצור מודול ייעודי לבדיקות עם מכשור כדי לבודד את שאר הקוד מהבדיקות, צריך ליצור מודול בדיקה נפרד ולהגדיר את ה-build שלו באופן דומה לזה של מודול ספרייה.

כדי ליצור מודול בדיקה:

  1. יצירת מודול של ספרייה
  2. בקובץ build.gradle ברמת המודול, מחילים את הפלאגין com.android.test במקום com.android.library.
  3. לוחצים על סנכרון הפרויקט .

אחרי שיוצרים את מודול הבדיקה, אפשר לכלול את קוד הבדיקה בקבוצת המקורות הראשית או בקבוצת המקורות של הווריאציה (לדוגמה, src/main/kotlin+java או src/variant/kotlin+java). אם מודול האפליקציה מגדיר כמה גרסאות מוצר, אפשר ליצור מחדש את הגרסאות האלה במודול הבדיקה. באמצעות ניהול תלויות שמודע לווריאנטים, מודול הבדיקה מנסה לבדוק את הטעם התואם במודול היעד.

כברירת מחדל, מודולי הבדיקה מכילים רק גרסת ניפוי באגים ונבדקים רק בה. עם זאת, אתם יכולים ליצור סוגי build חדשים שיתאימו לפרויקט האפליקציה שנבדק. כדי שהמודול test יבדוק סוג build אחר ולא את סוג ה-debug, משתמשים ב-VariantFilter כדי להשבית את וריאנט ה-debug בפרויקט הבדיקה, כמו שמוצג כאן:

Kotlin

android {
    variantFilter {
        if (buildType.name == "debug") {
            ignore = true
        }
    }
}

מגניב

android {
    variantFilter { variant ->
        if (variant.buildType.name.equals('debug')) {
            variant.setIgnore(true);
        }
    }
}

אם רוצים שמודול בדיקה יטרגט רק טעמים מסוימים או סוגי build מסוימים של אפליקציה, אפשר להשתמש במאפיין matchingFallbacks כדי לטרגט רק את הווריאציות שרוצים לבדוק. בנוסף, כך מודול הבדיקה לא צריך להגדיר את הווריאציות האלה בעצמו.