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

אתם יכולים לבדוק את אפליקציית 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() override כדי לשנות את הצפיפות באופן מקומי, וכך מאלץ את ה-composable‏ 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.