בדיקות אינסטרומנטציה

קודם כדאי לקרוא את המאמר בדיקת האפליקציה באתר developer.android.com. חשוב לזכור שיש כמה הבדלים באופן שבו נעשה שימוש בבדיקות של מכשירי המדידה בבדיקת הפלטפורמה.

לסיכום, בדיקת מכשור מספקת סביבה מיוחדת לביצוע בדיקות, שמופעל באמצעות הפקודה am instrument. בתהליך הזה, תהליך האפליקציה המטורגט מופעל מחדש ומאותחם עם הקשר בסיסי של האפליקציה, וחווט מכשור מופעל בתוך המכונה הווירטואלית של תהליך האפליקציה. קוד הבדיקה מתחיל לפעול בשרשור המדידה הזה, ומקבל מופע של Instrumentation שמספק גישה להקשר של האפליקציה ולממשקי ה-API כדי לבצע פעולות על תהליך האפליקציה שנבדק.

מושגים מרכזיים

  • צריך להצהיר על מכשיר למדידת ביצועים בחבילת אפליקציה, באמצעות תג <instrumentation> שמוקן בתוך התג <manifest> של המניפסט של חבילת האפליקציה.
  • מבחינה טכנית, מניפסט של חבילת אפליקציה יכול להכיל כמה תגי <instrumentation>, אבל בדרך כלל לא משתמשים בו בצורה הזו.
  • כל <instrumentation> חייב להכיל:
    • מאפיין android:name: זה צריך להיות השם של תת-סוג של Instrumentation שמופיע באפליקציית הבדיקה, בדרך כלל הכלי להרצת הבדיקות שבו נעשה שימוש. לדוגמה: android.support.test.runner.AndroidJUnitRunner
    • צריך להגדיר מאפיין android:targetPackage. הערך צריך להיות מוגדר לחבילת האפליקציה שנבדקת.

סיכום השלבים

  1. אלה יעדים נפוצים לבדיקות אטומות של שירותי מסגרת:

    frameworks/base/core/tests/coretests
frameworks/base/services/tests/servicestests

    אם אתם מוסיפים מודול חדש לגמרי למדידה של הרכיב, תוכלו לעיין במאמר

  2. לפי המוסכמה הקיימת, אם מוסיפים בדיקות לאחד מהמיקומים שלמעלה. אם מגדירים מודול בדיקה חדש, צריך לפעול לפי ההוראות להגדרה של AndroidManifest.xml ו-Android.mk באחד מהמיקומים שלמעלה.

  3. לדוגמה, frameworks/base/core/tests/coretests/. שימו לב שהשורות האלה מתקינות אפליקציות נוספות:

    <option name="test-file-name" value="FrameworksCoreTests.apk" />
<option name="test-file-name" value="BstatsTestApp.apk" />

  4. חשוב לא לשכוח לסמן את הבדיקה בתור @SmallTest, ‏ @MediumTest או @LargeTest

  5. יצירת מודול הבדיקה באמצעות m, למשל:

    m FrameworksCoreTests

  6. מריצים את הבדיקות:

    m tradefed-all
tradefed.sh run template/local_min --template:map test=FrameworksCoreTests

  7. אם אתם לא משתמשים ב-Tradefed, עליכם להתקין את הבדיקות ולהריץ אותן באופן ידני:

    1. מתקינים את קובץ ה-APK שנוצר:
    adb install -r ${OUT}/data/app/FrameworksCoreTests/FrameworksCoreTests.apk

    1. מריצים את הבדיקות עם אפשרויות שונות:

      1. כל הבדיקות ב-APK

        adb shell am instrument -w com.android.frameworks.coretests\
  /android.support.test.runner.AndroidJUnitRunner

      2. כל הבדיקות בחבילת Java ספציפית

        adb shell am instrument -w -e package android.animation \
  com.android.frameworks.coretests\
  /android.support.test.runner.AndroidJUnitRunner

      3. כל הבדיקות בכיתה ספציפית

        adb shell am instrument -w -e class \
  android.animation.AnimatorSetEventsTest \
  com.android.frameworks.coretests\
  /android.support.test.runner.AndroidJUnitRunner

      4. שיטת בדיקה ספציפית

        adb shell am instrument -w -e class \
  android.animation.AnimatorSetEventsTest#testCancel \
  com.android.frameworks.coretests\
  /android.support.test.runner.AndroidJUnitRunner

הבדיקה יכולה לבצע טענת נכוֹנוּת (assertion) מפורשת על אישור או על כישלון באמצעות ממשקי ה-API של JUnit. בנוסף, כל חריגה שלא תתפס תגרום גם לכישלון פונקציונלי.

כדי לשדר מדדי ביצועים, קוד הבדיקה יכול להפעיל את Instrumentation#sendStatus כדי לשלוח רשימה של צמדי מפתח/ערך. חשוב לזכור:

  1. המדדים יכולים להיות מספרים שלמים או מספרים עשרוניים
  2. ערכים לא מספריים יידחו
  3. קובץ ה-APK לבדיקה יכול לכלול בדיקות פונקציונליות או בדיקות מדדים, אבל כרגע אין תמיכה בשילוב של שתיהן