הגדר את Sharding

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

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

ניתן להגנה או לא להגנה?

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

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

  • כאשר ההתקנה של המודול שלך יקרה:

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

  • כאשר מספר הבדיקות במודול שלך נמוך:

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

מבחני מכשור: מספר מקסימלי של רסיסים?

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

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

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

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

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

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