סנכרון הבדיקות

בדיקות ה-Compose מסונכרנות כברירת מחדל עם ממשק המשתמש. כשקוראים לאימרה או לפעולה עם ComposeTestRule, הבדיקה מסתנכרנת מראש ומחכה עד שצירוף עץ ממשק המשתמש יהיה במצב חוסר פעילות.

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

כשמפעילים סנכרון של בדיקה, אפליקציית Compose מתקדמת בזמן באמצעות שעון וירטואלי. המשמעות היא שבדיקות Compose לא פועלות בזמן אמת, כדי שהן יוכלו לעבור כמה שיותר מהר.

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

@Test
fun counterTest() {
    val myCounter = mutableStateOf(0) // State that can cause recompositions.
    var lastSeenValue = 0 // Used to track recompositions.
    composeTestRule.setContent {
        Text(myCounter.value.toString())
        lastSeenValue = myCounter.value
    }
    myCounter.value = 1 // The state changes, but there is no recomposition.

    // Fails because nothing triggered a recomposition.
    assertTrue(lastSeenValue == 1)

    // Passes because the assertion triggers recomposition.
    composeTestRule.onNodeWithText("1").assertExists()
}

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

השבתת הסנכרון האוטומטי

כשאתם קוראים לטענת נכוֹנוּת או לפעולה דרך ComposeTestRule, כמו assertExists(), הבדיקה מסתנכרנת עם ממשק המשתמש של Compose. במקרים מסוימים, כדאי להפסיק את הסנכרון הזה ולשלוט בשעון בעצמכם. לדוגמה, תוכלו לקבוע מתי לצלם צילומי מסך מדויקים של אנימציה, בשלב שבו ממשק המשתמש עדיין יהיה פעיל. כדי להשבית את הסנכרון האוטומטי, מגדירים את המאפיין autoAdvance בקובץ mainClock לערך false:

composeTestRule.mainClock.autoAdvance = false

בדרך כלל תצטרכו לקדם את הזמן בעצמכם. אפשר להתקדם בדיוק תמונה אחת באמצעות advanceTimeByFrame() או למשך זמן מסוים באמצעות advanceTimeBy():

composeTestRule.mainClock.advanceTimeByFrame()
composeTestRule.mainClock.advanceTimeBy(milliseconds)

משאבים שאינם פעילים

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

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

ה-API הזה דומה מאוד ל-Idling Resources של Espresso, כדי לציין אם הנושא בבדיקה לא פעיל או עמוס. משתמשים בכללי הבדיקה Compose כדי לרשום את ההטמעה של IdlingResource.

composeTestRule.registerIdlingResource(idlingResource)
composeTestRule.unregisterIdlingResource(idlingResource)

סנכרון ידני

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

הפונקציה waitForIdle() ממתינה עד שתהליך הכתיבה לא יהיה פעיל, אבל היא תלויה במאפיין autoAdvance:

composeTestRule.mainClock.autoAdvance = true // Default
composeTestRule.waitForIdle() // Advances the clock until Compose is idle.

composeTestRule.mainClock.autoAdvance = false
composeTestRule.waitForIdle() // Only waits for idling resources to become idle.

לתשומת ליבכם: בשני המקרים, waitForIdle() בהמתנה גם לאישורי מעבר לשרטוט ופריסה בהמתנה.

אפשר גם להעביר את השעון קדימה עד שתנאי מסוים מתקיים באמצעות advanceTimeUntil().

composeTestRule.mainClock.advanceTimeUntil(timeoutMs) { condition }

חשוב לזכור שהתנאי צריך לבדוק את המצב שיכול להיות מושפע מהשעון הזה (הוא פועל רק במצב 'כתיבה').

המתנה לתנאים

בכל תנאי שתלויות בעבודה חיצונית, כמו טעינת נתונים או מדידה או ציור ב-Android (כלומר מדידה או ציור מחוץ ל-Compose), צריך להשתמש במושג כללי יותר כמו waitUntil():

composeTestRule.waitUntil(timeoutMs) { condition }

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

composeTestRule.waitUntilAtLeastOneExists(matcher, timeoutMs)

composeTestRule.waitUntilDoesNotExist(matcher, timeoutMs)

composeTestRule.waitUntilExactlyOneExists(matcher, timeoutMs)

composeTestRule.waitUntilNodeCount(matcher, count, timeoutMs)

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

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