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

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

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

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

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

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

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

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

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

1. בחלון Project, לוחצים על התפריט ובוחרים בתצוגה Project.
2. בתיקיית המודול המתאימה, לוחצים לחיצה ימנית על תיקיית src ואז לוחצים על חדש > Google Directory.
3. בשדה של שם הספרייה, מזינים androidTestVariantName. לדוגמה, אם יש לכם גרסת build שנקראת MyFlavor, שימוש בשם הספרייה androidTestMyFlavor
4. לוחצים על אישור.
5. לוחצים לחיצה ימנית על הספרייה החדשה ובוחרים באפשרות New > Google Directory.
6. מזינים '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 כדי הצגת התיקיות שבהן נעשה שימוש:

איור 1. נבחר וריאנט אחד (MyFlavor); ה התיקייה androidTestMyFlavor מוצגת בתצוגת Android.

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

איור 2. נבחר וריאנט אחד (OtherFlavor); ה התיקייה androidTestMyFlavor לא מופיעה בתצוגת Android.

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

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

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

איור 4. נבחר וריאנט אחד (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 שלו באופן דומה לזה של מודול ספרייה.

כדי ליצור מודול בדיקה, מבצעים את הפעולות הבאות:

1. יוצרים מודול של ספרייה.
2. בקובץ build.gradle ברמת המודול, מחילים את ה-com.android.test במקום com.android.library.
3. לוחצים על 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 כדי לטרגט רק את הווריאנטים שרוצים לבדוק. הפעולה הזו מונעת גם כי הוא לא צריך להגדיר את הווריאציות האלה בעצמו.