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

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

בדיקה בבידוד

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

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

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

לעתים קרובות צריך להגדיר את התוכן שנבדק באמצעות 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() כדי לשנות את הצפיפות באופן מקומי, וכך מאלץ את הקומפוזיציה MyScreen לעבור עיבוד בחלון גדול לרוחב, גם אם המכשיר שבו מריצים את הבדיקה לא תומך בגודל החלון הזה באופן ישיר:

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: למרות שהכלי מיועד לממשקי משתמש מבוססי-View, הידע ב-Espresso יכול לעזור גם בהיבטים מסוימים של בדיקות ב-Compose.