לכל מודול בדיקה חדש צריך להיות קובץ תצורה כדי להנחות את מערכת ה-build לגבי המטא-נתונים של המודול, יחסי התלות בזמן הידור והוראות האריזה. ב-Android נעשה עכשיו שימוש במערכת ה-build של Soong כדי להגדיר בדיקות בצורה פשוטה יותר.
ב-Soong נעשה שימוש בקובצי Blueprint או .bp, שהם תיאורים פשוטים ודקלרטיביים של מודולים ל-build, בדומה ל-JSON. הפורמט הזה מחליף את המערכת שמבוססת על Make שהייתה בשימוש בגרסאות קודמות. פרטים מלאים זמינים בקובצי העזר של Soong במרכז הבקרה של השילוב המתמשך.
כדי לבצע בדיקות בהתאמה אישית או להשתמש בחבילת בדיקות התאימות (CTS) של Android, צריך לפעול לפי ההוראות במאמר הגדרת בדיקה מורכבת.
דוגמה
הרשומות הבאות מגיעות מקובץ התצורה לדוגמה של Blueprint: /platform_testing/tests/example/instrumentation/Android.bp
צירפנו כאן תמונת מצב לצורך נוחות:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
שימו לב שההצהרה android_test בהתחלה מציינת שמדובר בבדיקה.
אם תכללו את android_app, המשמעות תהיה שמדובר בחבילת build.
הגדרות
ההגדרות הבאות מפורטות בהמשך:
name: "HelloWorldTests",
ההגדרה name נדרשת כשמציינים את סוג המודול android_test (בתחילת הבלוק). השם הזה יקבע את השם של המודול, ושם קובץ ה-APK שייווצר יהיה זהה עם הסיומת .apk. לדוגמה, במקרה הזה שם קובץ ה-APK לבדיקה יהיה HelloWorldTests.apk. בנוסף, הקוד הזה מגדיר גם שם יעד של make עבור המודול, כך שתוכלו להשתמש ב-make [options]
<HelloWorldTests> כדי ליצור את מודול הבדיקה ואת כל יחסי התלות שלו.
static_libs: ["androidx.test.runner"],
ההגדרה static_libs מורה למערכת ה-build לשלב את התוכן של המודולים שצוינו בחבילת ה-APK שמתקבלת מהמודול הנוכחי. המשמעות היא שכל מודול בעל שם אמור ליצור קובץ .jar, והתוכן שלו ישמש לפתרון הפניות ל-classpath במהלך הזמן של הידור, וגם ישולב ב-APK שנוצר.
המודול androidx.test.runner הוא ה-build מראש של ספריית AndroidX Test Runner, שכוללת את ה-test runner AndroidJUnitRunner.
AndroidJUnitRunner תומך במסגרת הבדיקה JUnit4 והחליף את InstrumentationTestRunner ב-Android 10. מידע נוסף על בדיקת אפליקציות ל-Android זמין במאמר בדיקת אפליקציות ב-Android.
אם אתם מפתחים מודול חדש של מכשור, תמיד כדאי להתחיל עם הספרייה androidx.test.runner בתור הכלי להרצת הבדיקה. עץ המקור של הפלטפורמה כולל גם מסגרות בדיקה שימושיות אחרות, כמו ub-uiautomator, mockito-target, easymock ועוד.
certificate: "platform",
ההגדרה certificate מורה למערכת ה-build לחתום על קובץ ה-APK באמצעות אותו אישור של פלטפורמת הליבה. צריך להשתמש באפשרות הזו אם הבדיקה כוללת הרשאה או ממשק API שמוגנים בחתימת אימות. חשוב לזכור שהשיטה הזו מתאימה לבדיקות רציפה של פלטפורמות, אבל לא צריך להשתמש בה במודולים של בדיקות CTS. חשוב לזכור שבדוגמה הזו נעשה שימוש בהגדרת האישור הזו רק לצורך המחשה: קוד הבדיקה בדוגמה לא דורש בפועל שחבילת ה-APK לבדיקה תיחתם באמצעות אישור הפלטפורמה המיוחד.
אם אתם כותבים כלי למדידה לרכיב שנמצא מחוץ לשרת המערכת, כלומר הוא ארוז בערך כמו קובץ APK של אפליקציה רגילה, מלבד העובדה שהוא מוטמע בתמונת המערכת ויכול להיות שהוא אפליקציה בעלת הרשאות, סביר להניח שהכלי למדידה יטרגט את חבילת האפליקציה (ראו בהמשך הקטע בנושא מניפסט) של הרכיב. במקרה כזה, יכול להיות שלקובץ ה-makefile של האפליקציה תהיה הגדרה משלו של certificate, ומודול המדידה צריך לשמור על אותה הגדרה. הסיבה לכך היא שכדי לטרגט את הכלים באפליקציה שנבדקת, חבילת ה-APK לבדיקה וחבילת ה-APK של האפליקציה צריכות להיות חתומות באותו אישור.
במקרים אחרים, אין צורך בהגדרה הזו בכלל: מערכת ה-build פשוט תחתום עליו באמצעות אישור מובנה שמוגדר כברירת מחדל, על סמך וריאנט ה-build, והוא נקרא בדרך כלל dev-keys.
test_suites: ["device-tests"],
ההגדרה test_suites מאפשרת לכלי הבדיקה של Trade Federation למצוא בקלות את הבדיקה. אפשר להוסיף כאן חבילות אחרות, כמו CTS, כדי לשתף את הבדיקה.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
הגדרות אופציונליות
בהמשך מוסבר על ההגדרות האופציונליות הבאות:
test_config: "path/to/hello_world_test.xml"
ההגדרה test_config מורה למערכת ה-build שצריך הגדרה ספציפית ליעד הבדיקה. כברירת מחדל, הערך AndroidTest.xml לצד Android.bp משויך לתצורה.
auto_gen_config: true
ההגדרה auto_gen_config מציינת אם ליצור את הגדרות הבדיקה באופן אוטומטי או לא. אם הערך AndroidTest.xml לא קיים לצד הערך Android.bp, אין צורך להגדיר את המאפיין הזה לערך true במפורש.
require_root: true
ההגדרה require_root מורה למערכת ה-build להוסיף את RootTargetPreparer להגדרת הבדיקה שנוצרה באופן אוטומטי. כך מובטח שהבדיקה תפעל עם הרשאות root.
test_min_api_level: 29
ההגדרה test_min_api_level מורה למערכת ה-build להוסיף את MinApiLevelModuleController להגדרת הבדיקה שנוצרה באופן אוטומטי. כש-Trade Federation מפעיל את הגדרת הבדיקה, הבדיקה תידלג אם ערך המאפיין של המכשיר ro.product.first_api_level < test_min_api_level.