מיפוי בדיקות

זוהי הקדמה קצרה למיפוי בדיקות והסבר על תחילת ההגדרה של בדיקות ב-פרויקט קוד פתוח של Android‏ (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 או באחת מספריות המשנה שלו. צריך להוסיף תו בריחה ללוכסנים (\) כי הם נמצאים בקובץ JSON.

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

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

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

tradefed.sh run commandAndExit [test_module] --help

מידע נוסף על האופן שבו האפשרויות פועלות זמין במאמר בנושא טיפול באפשרויות ב-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, מורצות רק בדיקות presubmit שהוגדרו בקובץ 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"
    }
  ]
}