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

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

לסיכום, בדיקת אינסטרומנטציה מספקת סביבת ביצוע בדיקה מיוחדת, שמופעלת באמצעות הפקודה am instrument, שבה תהליך האפליקציה הממוקדת מופעל מחדש ומאותחל עם הקשר בסיסי של האפליקציה, ושרשור אינסטרומנטציה מופעל בתוך מכונת ה-VM של תהליך האפליקציה. קוד הבדיקה מתחיל לפעול בשרשור המכשיר הזה ומקבל מופע של 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. מריצים את הבדיקות:

    • הפתרון הכי פשוט הוא להשתמש ב-Atest באופן הבא:

      atest FrameworksCoreTests

    • לחלופין, כדי לבצע בדיקות מורכבות יותר, אפשר להשתמש בTrade Federation test Harness:

    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

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

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

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