מיפוי בדיקות

זוהי הקדמה קצרה למיפוי בדיקות והסבר על תחילת ההגדרה של בדיקות ב-Android Open Source Project‏ (AOSP).

מידע על מיפוי בדיקות

מיפוי בדיקות הוא גישה שמבוססת על Gerrit ומאפשרת למפתחים ליצור כללי בדיקה לפני שליחה ואחרי שליחה ישירות בעץ המקור של Android, ולהשאיר את ההחלטות לגבי הענפים והמכשירים שייבדקו לתשתית הבדיקה. הגדרות מיפוי של בדיקות הן קובצי JSON בשם TEST_MAPPING שאפשר למקם בכל ספריית מקור.

‫Atest יכול להשתמש בקבצים TEST_MAPPING כדי להריץ בדיקות לפני שליחה בספריות המשויכות. באמצעות מיפוי בדיקות, אפשר להוסיף את אותו סט בדיקות לבדיקות לפני שליחה עם שינוי מינימלי בתוך עץ המקור של Android.

דוגמאות:

מיפוי הבדיקות מסתמך על Trade Federation (TF) test harness להרצת בדיקות ולדיווח על תוצאות.

הגדרת קבוצות בדיקה

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

כללים לסקריפט ליצירת חבילה

כדי ש-Trade Federation test harness יפעיל מודולי בדיקה עבור גרסת build מסוימת, המודולים האלה צריכים לכלול test_suites שמוגדר ל-Soong או LOCAL_COMPATIBILITY_SUITE שמוגדר ל-Make לאחת משתי חבילות הבדיקה האלה:

  • ‫general-tests מיועד לבדיקות שלא תלויות ביכולות ספציפיות למכשיר (כמו חומרה ספציפית לספק שאין ברוב המכשירים). רוב הבדיקות צריכות להיות בחבילת general-tests, גם אם הן ספציפיות ל-ABI אחד, לרוחב סיביות אחד או לתכונות חומרה כמו HWASan (יש יעד test_suites נפרד לכל ABI), וגם אם הן צריכות לפעול במכשיר.
  • ‫device-tests מיועד לבדיקות שתלויות ביכולות ספציפיות למכשיר. בדרך כלל הבדיקות האלה נמצאות בקטע vendor/. ספציפי למכשיר מתייחס רק ליכולות שייחודיות למכשיר מסוים, ולכן זה רלוונטי לבדיקות JUnit וגם לבדיקות GTest (שבדרך כלל צריך לסמן אותן כ-general-tests גם אם הן ספציפיות ל-ABI).

לדוגמה:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

הגדרת בדיקות להרצה בחבילת בדיקות

כדי שבדיקה תפעל בתוך חבילת בדיקות, הבדיקה צריכה:

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

  • לא כדאי להניח שמכשיר נמצא במצב מסוים, למשל מוכן לביצוע פעולת Root. ברוב הבדיקות לא נדרשת הרשאת root כדי להריץ אותן. אם בדיקה צריכה הרשאת root, צריך לציין זאת באמצעות RootTargetPreparer ב-AndroidTest.xml שלה, כמו בדוגמה הבאה:

    <target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

יצירת קובצי מיפוי לבדיקה

בספרייה שנדרש כיסוי בדיקות עבורה, מוסיפים קובץ JSON‏ TEST_MAPPING שדומה לדוגמה. הכללים האלה מבטיחים שהבדיקות יפעלו בבדיקות לפני שליחה (presubmit) כשמבצעים שינויים בקבצים בספרייה הזו או בכל אחת מהספריות המשניות שלה.

דוגמה

זו דוגמה לקובץ TEST_MAPPING (בפורמט JSON, אבל עם תמיכה בהערות):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsDeqpTestCases",
      "options": [
        {
          // Use regex in include-filter which is supported in AndroidJUnitTest
          "include-filter": "dEQP-EGL.functional.color_clears.*"
        }
      ]
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

הגדרת מאפיינים

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

אפשר להגדיר את השם של מודול הבדיקה או את השם של בדיקת השילוב של Trade Federation (נתיב המשאב לקובץ ה-XML של הבדיקה, לדוגמה, uiautomator/uiautomator-demo) בערך של מאפיין name. שימו לב: בשדה name אי אפשר להשתמש במחלקה name או בשיטת הבדיקה name. כדי לצמצם את הבדיקות שיופעלו, אפשר להשתמש באפשרויות כמו include-filter. include-filter דוגמאות לשימוש

ההגדרה host של בדיקה מציינת אם הבדיקה היא בדיקה ללא מכשיר שפועלת במארח או לא. ערך ברירת המחדל הוא false, כלומר כדי להריץ את הבדיקה נדרש מכשיר. סוגי הבדיקות הנתמכים הם HostGTest לקבצים בינאריים של GTest ו-HostTest לבדיקות JUnit.

המאפיין file_patterns מאפשר להגדיר רשימה של מחרוזות ביטוי רגולרי להתאמה לנתיב היחסי של כל קובץ קוד מקור (ביחס לספרייה שמכילה את הקובץ TEST_MAPPING). בדוגמה, הבדיקה CtsWindowManagerDeviceTestCases מופעלת לפני שליחת הקוד רק אם קובץ Java מתחיל ב-Window או ב-Activity, וקיים באותה ספרייה כמו קובץ TEST_MAPPING או באחת מספריות המשנה שלו. צריך להוסיף תו escape ללוכסנים (\) כי הם נמצאים בקובץ JSON.

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

המאפיין options מכיל אפשרויות נוספות של שורת פקודה ב-Tradefed.

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

tradefed.sh run commandAndExit [test_module] --help

מידע נוסף על אופן הפעולה של האפשרויות מופיע במאמר Option handling in Tradefed.

הרצת בדיקות באמצעות Atest

כדי להריץ את כללי הבדיקה לפני השליחה באופן מקומי:

  1. עוברים לספרייה שמכילה את הקובץ TEST_MAPPING.

  2. מריצים את הפקודה:

    atest

כל הבדיקות לפני שליחה שמוגדרות בקובצי TEST_MAPPING של הספרייה הנוכחית ושל ספריות ההורה שלה מופעלות. ‫Atest מאתר ומריץ שתי בדיקות (A ו-B) לפני שליחת הקוד.

זו הדרך הכי פשוטה להריץ בדיקות לפני שליחה בTEST_MAPPING קבצים בספריית העבודה הנוכחית (CWD) ובספריות האב. ‫Atest מאתר את הקובץ TEST_MAPPING ב-CWD ומשתמש בו, וגם בכל ספריות האב שלו.

קוד מקור של מבנה

בדוגמה הזו אפשר לראות איך להגדיר קובצי TEST_MAPPING בעץ המקור:

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

תוכן של src/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

תוכן של src/project_1/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

תוכן של src/project_2/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

ציון ספריות יעד

אתם יכולים לציין ספריית יעד להרצת בדיקות בקובצי TEST_MAPPING בספרייה הזו. הפקודה הבאה מריצה שתי בדיקות (A, B):

atest --test-mapping src/project_1

הרצת כללי בדיקה אחרי שליחה

אפשר להשתמש בפקודה הזו גם כדי להריץ את כללי הבדיקה של postsubmit שמוגדרים ב-TEST_MAPPING ב-src_path (ברירת המחדל היא CWD) ובספריות ברמה העליונה שלה:

atest [--test-mapping] [src_path]:postsubmit

הפעלה רק של בדיקות שלא נדרש בהן מכשיר

אפשר להשתמש באפשרות --host עבור Atest כדי להריץ רק את הבדיקות שהוגדרו מול המארח שלא נדרש לו מכשיר. בלי האפשרות הזו, Atest מריץ את שני סוגי הבדיקות: בדיקות שדורשות מכשיר ובדיקות שרצות במארח שלא דורש מכשיר. הבדיקות מופעלות בשני חבילות נפרדות:

atest [--test-mapping] --host

זיהוי קבוצות בדיקה

אפשר לציין קבוצות בדיקה בפקודה Atest. הפקודה הבאה מריצה את כל הבדיקות של postsubmit שקשורות לקבצים בספרייה src/project_1, שמכילה רק בדיקה אחת (C):

אפשר גם להשתמש ב-:all כדי להריץ את כל הבדיקות בלי קשר לקבוצה. הפקודה הבאה מפעילה ארבע בדיקות (A,‏ B,‏ C ו-X):

atest --test-mapping src/project_1:all

כולל ספריות משנה

כברירת מחדל, כשמריצים בדיקות ב-TEST_MAPPING באמצעות Atest, מורצות רק בדיקות לפני שליחה שהוגדרו בקובץ TEST_MAPPING ב-CWD (או בספרייה שצוינה) ובספריות ברמה העליונה שלה. אם רוצים להריץ בדיקות בכל הקבצים TEST_MAPPING בספריות המשנה, צריך להשתמש באפשרות --include-subdir כדי לחייב את Atest לכלול גם את הבדיקות האלה.

atest --include-subdir

אם לא מציינים את האפשרות --include-subdir, הפקודה Atest מריצה רק את הבדיקה A. באפשרות --include-subdir, ‏ Atest מריץ שתי בדיקות (A, ‏ B).

תמיכה בתגובות ברמת השורה

אתם יכולים להוסיף הערה בפורמט // ברמת השורה כדי להוסיף תיאור להגדרה שמופיעה בקובץ TEST_MAPPING. ‫ATest ו-Trade Federation מבצעים עיבוד מקדים של TEST_MAPPING לפורמט JSON תקין ללא הערות. כדי לשמור על קובץ ה-JSON נקי, נתמך רק //פורמט ההערה ברמת השורה.

דוגמה:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}