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

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

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

      atest FrameworksCoreTests
      
    • לבדיקות מורכבות יותר, אפשר להשתמש ב-Trade Federation 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
        

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

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

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