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

[עדכון 2023] בקצרה: צריך להשתמש בממשקי ה-API החדשים של waitUntil כדי לבצע סנכרון בבדיקות של Compose (גרסה 1.4.0 ואילך).

מהו סנכרון?

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

כדי להציג את התמונה בגודל מלא, מקישים על Enter או לוחצים

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

כדי להציג את התמונה בגודל מלא, מקישים על Enter או לוחצים

androidx.test ובאופן כללי, הכלי לבדיקת ניסוח משתמש בטריקים שונים כדי שלא תצטרכו לדאוג יותר מדי לגבי זה. לדוגמה, אם ה-thread הראשי עמוס, הבדיקה מושהית עד שאפשר להריץ את השורה הבאה.

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

אפשרות 1: משאבים במצב המתנה

‫Idling Resources היא תכונה של Espresso שמאפשרת לכם, המפתחים, להחליט מתי האפליקציה עסוקה. יש שתי דרכים להשתמש בהם:

1. התקנה שלהם במסגרת או בספרייה שמבצעת עבודה שהבדיקה לא יכולה לראות.

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

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

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

זה לא אידיאלי כי אתם מזהמים את קוד הייצור או יוצרים כפילויות מסובכות לבדיקה, ויש מצבים שבהם קשה להתקין אותם. לדוגמה, איך משתמשים ב-Idling Resources ב-Kotlin Flow? איזה עדכון הוא האחרון?

במקום זאת, אפשר לחכות לדברים.

אפשרות 2: המתנה לדברים… בדרך הלא נכונה

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

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

בנוסף, לפעמים אמולטורים או מכשירים מתנהגים בצורה לא תקינה ומתרחשים בהם בעיות בממשק (jank), ולכן הפעולה אורכת קצת יותר מ-2,000 מילי-שניות, מה שגורם לבעיה ב-build. כשמריצים מאות בדיקות, הבעיה הזו הופכת להיות משמעותית מאוד.

אפשרות 3: מחכים בצורה הנכונה!

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

ב-Compose, אפשר להשתמש בפונקציה waitUntil, שמקבלת פונקציה אחרת שמפיקה ערך בוליאני.

עדכון מ-22 במרץ 2023: החל מ-Compose 1.4.0, הוספנו קבוצה חדשה של ממשקי API מסוג waitUntil:

‫[Before 1.4.0: Use these helpers: waitUntilExists, waitUntilNodeCount]

…וכך משתמשים בהם:

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

אז מתי כדאי להשתמש בזה? תרחיש שימוש טוב הוא טעינת נתונים מ-observable (עם LiveData, ‏ Kotlin Flow או RxJava). אם ממשק המשתמש צריך לקבל כמה עדכונים לפני שהוא נחשב למצב בלי פעילות, כדאי לפשט את הסנכרון באמצעות waitUntil.

לדוגמה, כשמייבאים זרימה מתצוגה:

ואתם שולחים אליו כמה פריטים:

אם הפונקציה repository לא מחזירה את התוצאה הראשונה אחרי פרק זמן לא מוגדר, מסגרת הבדיקה תחשוב שהמצב 'טעינה' הוא המצב 'בטלה' (הערך ההתחלתי שהוקצה ב-collectAsState) ותמשיך להצהרה הבאה.

לכן, כדי שהבדיקה תהיה אמינה יותר, צריך לוודא שממשק המשתמש לא מציג את אינדיקטור הטעינה:

שיהיה לכם… רגע… ניסוי מוצלח!

רישיון לקטעי קוד:

Copyright 2022 Google LLC.
SPDX-License-Identifier: Apache-2.0