לכל מודול בדיקה חדש צריך להיות קובץ תצורה כדי להנחות את מערכת ה-build באמצעות מטא-נתונים של המודול, יחסי תלות בזמן הידור והוראות לאריזה. ב-Android נעשה עכשיו שימוש במערכת ה-build של Soong כדי להגדיר בדיקות בצורה פשוטה יותר.
ב-Soong נעשה שימוש בקובצי Blueprint או .bp, שהם תיאורים פשוטים ודקלרטיביים של מודולים ל-build, בדומה ל-JSON. הפורמט הזה מחליף את המערכת שמבוססת על Make שהייתה בשימוש בגרסאות קודמות. פרטים מלאים מופיעים בקובצי העזר של Soong בלוח הבקרה של אינטגרציה רציפה (CI).
כדי לבצע בדיקות בהתאמה אישית או להשתמש בחבילת בדיקות התאימות (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.