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

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

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

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

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

@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()
}

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

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

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

composeTestRule.mainClock.autoAdvance = false

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

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

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

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

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

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

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

סנכרון ידני

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

הפונקציה 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 }

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

המתנה לתנאים

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