הגדרת חלוקה לפלחים

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

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

ניתן לחלוקה או לא ניתן לחלוקה?

אפשר לתייג מודול (AndroidTest.xml) באמצעות <option name="not-shardable" value="true" /> כדי להודיע למערכת שלא צריך לפצל אותו.

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

• אם ההגדרה של המודול יקרה:

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

• כשיש מספר קטן של בדיקות במודול:

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

בדיקות אינסטרומנטציה: מהו המספר המקסימלי של שברי בדיקה?

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

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

לכן, אם מספר הבדיקות בחבילת ה-APK של בדיקת אינסטרומנטציה נמוך, תיוג המודול באמצעות <option name="not-shardable" value="true" /> יאפשר למערכת לדעת שלא כדאי לפצל את המודול הזה.

ל-AndroidJUnitTest runner יש אפשרות מיוחדת שמאפשרת לו לציין את המספר המקסימלי של רסיסים שהוא יכול לפצל אליהם: <option name="ajur-max-shard" value="5" />.

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

לדוגמה, אם חבילת ה-APK של בדיקת אינסטרומנטציה מכילה רק שני מקרי בדיקה, אבל עדיין רוצים לפצל אותה, הגדרת הערך ajur-max-shard ל-2 תבטיח שלא ייצרו רסיסים ריקים.