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

קודם כדאי לקרוא את המאמר בדיקת האפליקציה באתר 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

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

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

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