הגדרות בדיקה מורכבות

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

• התקנה של חבילות APK אחרות (בנוסף לחבילת ה-APK לבדיקה)
• לדחוף קבצים מסוימים למכשיר
• להריץ פקודות (למשל adb shell pm ...)

בעבר, צוותי הרכיבים נאלצו בדרך כלל לכתוב בדיקה בצד המארח כדי לבצע משימות כאלה. לשם כך, הם נדרשו להבין את רתמת Trade Federation, והבדיקה הזו בדרך כלל הגדילה את המורכבות של מודול הבדיקה.

בהשראת CTS, הוספנו את המושג של הגדרת מודול בדיקה כדי לתמוך במשימות כאלה. אפשר לבצע את רשימת המשימות הנפוצות שלמעלה באמצעות כמה שורות הגדרה בלבד. כדי לקבל גמישות מקסימלית, אפשר אפילו להטמיע כלי משלכם להכנת יעד, כפי שמוגדר על ידי ITargetPreparer או ITargetCleaner, ולהגדיר אותו לשימוש בהגדרות של מודול הבדיקה שלכם.

קובץ תצורה של מודול בדיקה הוא קובץ XML נדרש שמתווסף לתיקיית המקור של המודול ברמה העליונה, בשם AndroidTest.xml. קובץ ה-XML עומד בפורמט של קובץ תצורה שמשמש את ערכת הכלים האוטומטית לבדיקות של Trade Federation. נכון לעכשיו, התגים הראשיים שמטופלים דרך הגדרות מודול הבדיקה הם התגים target_preparer ו-test.

גורמים שתצטרכו לטרגט

תג target_preparer, כפי ששמו מרמז, מגדיר כלי להכנת יעד (ראו ITargetPreparer) שמציע שיטת הגדרה, שנקראת לפני שמפעילים את מודול הבדיקה לצורך בדיקה. אם המחלקה שמצוינת בתג target_preparer מטמיעה גם את ITargetCleaner, שיטת ה-teardown שלה תופעל אחרי שמודול הבדיקה יסתיים.

כדי להשתמש בתצורה המשותפת המובנית של המודול, מוסיפים קובץ חדש בשם AndroidTest.xml בתיקייה ברמה העליונה של מודול הבדיקה, וממלאים אותו בתוכן הבא:

<?xml version="1.0" encoding="utf-8"?>
<!-- [insert standard AOSP copyright here] -->
<configuration description="Test module config for Foo">
<!-- insert options here -->
</configuration>

לדוגמה, אפשר להוסיף את תגי האפשרויות הבאים (בתגובה 'הוספה' שלמעלה):

    <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
        <option name="run-command" value="settings put secure accessibility_enabled 1" />
        <option name="teardown-command" value="settings put secure accessibility_enabled 0" />
    </target_preparer>

האפשרויות יגדירו את ערכת הבדיקה כך:

1. לפני שמפעילים את מודול הבדיקה, מריצים במכשיר את פקודת המעטפת 'settings put secure accessibility_enabled 1'
2. בסיום מודול הבדיקה, מריצים את פקודת המעטפת 'settings put secure accessibility_enabled 0'

בדוגמה הספציפית הזו, הנגישות מופעלת או מושבתת לפני או אחרי ההפעלה של מודול הבדיקה, בהתאמה. אחרי הדגמה של דוגמה פשוטה, נרחיב על אופן השימוש בתג 'option'. כפי שמוצג למעלה, לתג יכולים להיות שני מאפיינים: שם וערך. מאפיין השם חייב להפנות לאחת מהאפשרויות שהמתכנן מציע.

המטרה המדויקת של שדה הערך תלויה באופן שבו הגורם שהוכן את ה-template הגדיר את האפשרות: הוא יכול להיות מחרוזת, מספר, ערך בוליאני או אפילו נתיב של קובץ. לפניכם סיכום של שלושת הגורמים הנפוצים ליצירת יעדי מודעות:

• שם הכיתה: PushFilePreparer

  • שם מקוצר: push-file
  • function: דחיפה של קבצים שרירותיים מתיקיית מקרה הבדיקה ליעד במכשיר
  • notes:
    • הכלי הזה יכול לדחוף מתיקייה לתיקייה או מקובץ לקובץ. כלומר, אי אפשר לדחוף קובץ מתיקייה במכשיר: צריך לציין גם את שם הקובץ של היעד בתיקייה הזו.
  • options:
    • push-file: מפרט push שמציין את הקובץ המקומי לנתיב שבו צריך לדחוף אותו במכשיר. יכול להיות שהם יתרחשו שוב. אם הגדרתם שיותקפו כמה קבצים לאותו נתיב מרוחק, יועבר הקובץ העדכני ביותר.
    • push: (לא מומלץ) מפרט push, בפורמט /path/to/srcfile.txt->/path/to/destfile.txt או /path/to/srcfile.txt->/path/to/destdir/. אפשר לחזור עליו. הנתיב הזה יכול להיות יחסי לספריית מודול הבדיקה או לספריית out עצמה.
    • post-push: פקודה להרצה במכשיר (עם adb shell <your command>) אחרי שכל ניסיונות ההעברה בוצעו. תרחיש לדוגמה: שימוש ב-chmod להרשאות

• שם הכיתה: InstallApkSetup

  • שם מקוצר:install-apk
  • function: דחיפה של קובצי APK שרירותיים ליעד במכשיר
  • options:
    • test-file-name: השם של קובץ ה-APK שרוצים להתקין במכשיר.
    • install-arg: ארגומנטים נוספים שיועברו לפקודה pm install, כולל מקף תחילית, למשל '-d'. יכול להיות שיתבצעו חזרות

• שם הכיתה: RunCommandTargetPreparer

  • שם מקוצר: run-command
  • function: הפעלת פקודות מעטפת שרירותיות לפני או אחרי ביצוע מודול הבדיקה
  • options:
    • run-command:פקודת shell של adb להרצה. יכול להיות שיתבצעו חזרות
    • teardown-command: פקודה של מעטפת adb לצורך הפעלה במהלך שלב הפירוק. יכול להיות שיתבצעו חזרות

מחלקת בדיקה

כיתה לבדיקה היא הכיתה של Trade Federation שבה משתמשים כדי להריץ את הבדיקה.

<test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="android.test.example.helloworld"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>

ריכזנו כאן שלוש כיתות בדיקה נפוצות:

• שם הכיתה: GTest

  • שם קצר: gtest
  • function: בדיקה שמריצה חבילת בדיקה מקורית במכשיר נתון.
  • options:
    • native-test-device-path:הנתיב במכשיר שבו נמצאים הבדיקות המקומיות.

• שם הכיתה: InstrumentationTest

  • שם מקוצר: instrumentation
  • function: בדיקה שמריצה חבילת בדיקות של מכשור במכשיר נתון
  • options:
    • package:שם החבילה של המניפסט של אפליקציית הבדיקה ל-Android שרוצים להריץ.
    • class:שם הכיתה של הבדיקה שרוצים להריץ.
    • method: שם שיטת הבדיקה שרוצים להריץ.

• שם הכיתה: AndroidJUnitTest

  • function: בדיקה שמריצה חבילת בדיקת מכשור במכשיר נתון באמצעות android.support.test.runner.AndroidJUnitRunner. זוהי הדרך העיקרית להריץ בדיקת מכשור.