דפוסים נפוצים

אתם יכולים לבדוק את אפליקציית Compose באמצעות גישות ודפוסים מבוססים.

בדיקה בבידוד

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

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

גישה לפעילות ולמשאבים אחרי הגדרת התוכן שלכם

לעתים קרובות צריך להגדיר את התוכן שנבדק באמצעות composeTestRule.setContent, וגם לגשת למשאבי פעילות, למשל כדי לוודא שטקסט שמוצג תואם למשאב מחרוזת. עם זאת, אי אפשר להפעיל את setContent בכלל שנוצר באמצעות createAndroidComposeRule() אם הפעילות כבר מפעילה אותו.

דפוס נפוץ להשגת המטרה הזו הוא ליצור AndroidComposeTestRule באמצעות פעילות ריקה כמו ComponentActivity.

class MyComposeTest {

    @get:Rule
    val composeTestRule = createAndroidComposeRule<ComponentActivity>()

    @Test
    fun myTest() {
        // Start the app
        composeTestRule.setContent {
            MyAppTheme {
                MainScreen(uiState = exampleUiState, /*...*/)
            }
        }
        val continueLabel = composeTestRule.activity.getString(R.string.next)
        composeTestRule.onNodeWithText(continueLabel).performClick()
    }
}

הערה: צריך להוסיף את ComponentActivity לקובץ AndroidManifest.xml של האפליקציה. כדי להפעיל את התכונה, מוסיפים את יחסי התלות האלה למודול:

debugImplementation("androidx.compose.ui:ui-test-manifest:$compose_version")

מאפיינים סמנטיים מותאמים אישית

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

// Creates a semantics property of type Long.
val PickedDateKey = SemanticsPropertyKey<Long>("PickedDate")
var SemanticsPropertyReceiver.pickedDate by PickedDateKey

עכשיו משתמשים במאפיין הזה בשינוי semantics:

val datePickerValue by remember { mutableStateOf(0L) }
MyCustomDatePicker(
    modifier = Modifier.semantics { pickedDate = datePickerValue }
)

מבדיקות, משתמשים ב-SemanticsMatcher.expectValue כדי לקבוע את הערך של המאפיין:

composeTestRule
    .onNode(SemanticsMatcher.expectValue(PickedDateKey, 1445378400)) // 2015-10-21
    .assertExists()

אימות שחזור המצב

מוודאים שהמצב של רכיבי Compose משוחזר בצורה נכונה כשפעילות או תהליך נוצרים מחדש. אפשר לבצע בדיקות כאלה בלי להסתמך על יצירה מחדש של פעילות באמצעות המחלקה StateRestorationTester.

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

class MyStateRestorationTests {

    @get:Rule
    val composeTestRule = createComposeRule()

    @Test
    fun onRecreation_stateIsRestored() {
        val restorationTester = StateRestorationTester(composeTestRule)

        restorationTester.setContent { MainScreen() }

        // TODO: Run actions that modify the state

        // Trigger a recreation
        restorationTester.emulateSavedInstanceStateRestore()

        // TODO: Verify that state has been correctly restored.
    }
}

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

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

‫DeviceConfigurationOverride הוא API לבדיקה בלבד שמאפשר לדמות הגדרות שונות של מכשירים באופן מותאם לשוק המקומי עבור תוכן @Composable שנבדק.

לאובייקט הנלווה של DeviceConfigurationOverride יש את פונקציות ההרחבה הבאות, שמבטלות את מאפייני ההגדרה ברמת המכשיר:

• ‫DeviceConfigurationOverride.DarkMode(): מחליף את העיצוב הכהה או הבהיר של המערכת.
• ‫DeviceConfigurationOverride.FontScale(): שינוי של קנה המידה של גופן המערכת.
• ‫DeviceConfigurationOverride.FontWeightAdjustment(): מבטל את ההתאמה של עובי הגופן במערכת.
• ‫DeviceConfigurationOverride.ForcedSize(): כופה כמות מסוימת של מקום, ללא קשר לגודל המכשיר.
• ‫DeviceConfigurationOverride.LayoutDirection(): מחליף את כיוון הפריסה (משמאל לימין או מימין לשמאל).
• ‫DeviceConfigurationOverride.Locales(): מחליף את הלוקאל.
• ‫DeviceConfigurationOverride.RoundScreen(): ערך שמשנה את ברירת המחדל אם המסך עגול.

כדי להחיל שינוי ספציפי, עוטפים את התוכן שנבדק בקריאה לפונקציה ברמה העליונה DeviceConfigurationOverride(), ומעבירים את השינוי שרוצים להחיל כפרמטר.

לדוגמה, הקוד הבא מחיל את DeviceConfigurationOverride.ForcedSize() override כדי לשנות את הצפיפות באופן מקומי, וכך מאלץ את MyScreen composable לעבור רינדור בחלון גדול לרוחב, גם אם המכשיר שבו מופעל הבדיקה לא תומך בגודל החלון הזה באופן ישיר:

composeTestRule.setContent {
    DeviceConfigurationOverride(
        DeviceConfigurationOverride.ForcedSize(DpSize(1280.dp, 800.dp))
    ) {
        MyScreen() // Will be rendered in the space for 1280dp by 800dp without clipping.
    }
}
DeviceConfigurationOverrideSnippets.kt

כדי להחיל כמה שינויים ביחד, משתמשים ב-DeviceConfigurationOverride.then():

composeTestRule.setContent {
    DeviceConfigurationOverride(
        DeviceConfigurationOverride.FontScale(1.5f) then
            DeviceConfigurationOverride.FontWeightAdjustment(200)
    ) {
        Text(text = "text with increased scale and weight")
    }
}
DeviceConfigurationOverrideSnippets.kt

מקורות מידע נוספים

• בדיקת אפליקציות ב-Android: דף הנחיתה הראשי בנושא בדיקות ב-Android מספק סקירה רחבה יותר של עקרונות וטכניקות בדיקה.
• היסודות של בדיקות: מידע נוסף על המושגים הבסיסיים שמאחורי בדיקת אפליקציית Android.
• בדיקות מקומיות: אתם יכולים להריץ בדיקות מסוימות באופן מקומי, בתחנת העבודה שלכם.
• בדיקות עם מכשור: מומלץ להריץ גם בדיקות עם מכשור. כלומר, בדיקות שמופעלות ישירות במכשיר.
• אינטגרציה רציפה (CI): אינטגרציה רציפה מאפשרת לכם לשלב את הבדיקות בצינור הפריסה.
• בדיקה בגדלים שונים של מסכים: יש למשתמשים הרבה מכשירים שונים, ולכן כדאי לבדוק את האתר בגדלים שונים של מסכים.
• ‫Espresso: למרות שהכלי מיועד לממשקי משתמש מבוססי-תצוגה, הידע ב-Espresso עדיין יכול לעזור בחלק מההיבטים של בדיקות ב-Compose.