טירגוט של אפליקציה לדוגמה

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

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

מדריך זה משתמש בבדיקה הבאה כדי לספק דוגמה:

• frameworks/base/packages/Shell/tests

מומלץ לעיין קודם בקוד כדי לקבל רושם כללי לפני שממשיכים.

בחירת מיקום המקור

מכיוון שבדיקת האינסטרומנטציה תטרגט אפליקציה, המוסכמה הוא למקם את קוד המקור לבדיקה בספרייה tests מתחת לרמה הבסיסית (root) ספריית המקור של הרכיב בעץ המקור של הפלטפורמה.

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

קובץ מניפסט

בדיוק כמו באפליקציה רגילה, כל מודול של בדיקת אינסטרומנטציה זקוק קובץ מניפסט. אם השם של הקובץ הוא AndroidManifest.xml, צריך לציין אותו ל-Android.mk עבור מודול הבדיקה שלך, הוא ייכלל באופן אוטומטי על ידי קובץ makefile ליבה של BUILD_PACKAGE.

לפני שממשיכים, מומלץ מאוד לעבור על סקירה כללית של מניפסט האפליקציה קודם.

זוהי סקירה כללית של הרכיבים הבסיסיים בקובץ מניפסט החדשה.

ניתן לגשת לגרסה העדכנית של קובץ המניפסט לשינוי ה-Grit לדוגמה at: https://android.googlesource.com/platform/frameworks/base/+/main/packages/Shell/tests/AndroidManifest.xml.

לנוחותכם, מצורפת כאן תמונת מצב:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

    <application>
        <uses-library android:name="android.test.runner" />

        <activity
            android:name="com.android.shell.ActionSendMultipleConsumerActivity"
            android:label="ActionSendMultipleConsumer"
            android:theme="@android:style/Theme.NoDisplay"
            android:noHistory="true"
            android:excludeFromRecents="true">
            <intent-filter>
                <action android:name="android.intent.action.SEND_MULTIPLE" />
                <category android:name="android.intent.category.DEFAULT" />
                <data android:mimeType="*/*" />
            </intent-filter>
        </activity>
    </application>

    <instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
        android:targetPackage="com.android.shell"
        android:label="Tests for Shell" />

</manifest>

יש כמה הערות נבחרות בקובץ המניפסט:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

המאפיין package הוא שם החבילה של האפליקציה: זהו השם הייחודי שבו נעשה שימוש ב-framework של אפליקציות Android כדי לזהות (או בהקשר זה: אפליקציית הבדיקה שלך). כל משתמש במערכת יכול להתקין רק אפליקציה אחת עם שם החבילה הזה.

מאחר שזו חבילת אפליקציה לבדיקה, אינה תלויה באפליקציה החבילה בבדיקה, יש להשתמש בשם חבילה אחר: מוסכמה מקובלת אחת היא להוסיף את הסיומת .test.

בנוסף, המאפיין package זהה ComponentName#getPackageName() וגם את אותן פעולות שבהן אתם משתמשים כדי לבצע אינטראקציה עםpm פקודות באמצעות adb shell.

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

<uses-library android:name="android.test.runner" />

חובה לעשות זאת בכל בדיקות האינסטרומנטציה כי המחלקות הקשורות הן ארוזות בקובץ ספריית jars נפרד של framework, ולכן יש צורך בתוספת רשומות classpath כשחבילת הבדיקה מופעלת על ידי framework של האפליקציה.

android:targetPackage="com.android.shell"

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

קובץ תצורה פשוט

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

קובץ תצורה מורכב

לבדיקות מורכבות יותר, צריך גם לכתוב הגדרת תצורה לבדיקה .קובץ ה-SDK של Android, Trade Federation

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

ניתן לגשת לגרסה האחרונה של קובץ התצורה לשינוי ה-Grit לדוגמה at: frameworks/base/packages/Shell/tests/AndroidTest.xml

לנוחותכם, מצורפת כאן תמונת מצב:

<configuration description="Runs Tests for Shell.">
    <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
        <option name="test-file-name" value="ShellTests.apk" />
    </target_preparer>

    <option name="test-suite-tag" value="apct" />
    <option name="test-tag" value="ShellTests" />
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="com.android.shell.tests" />
        <option name="runner" value="android.support.test.runner.AndroidJUnitRunner" />
    </test>
</configuration>

יש כמה הערות נבחרות בקובץ התצורה לבדיקה:

<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
  <option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>

כך מורה ל-Trends Federation להתקין את ShellTests.APK באמצעות אופרטור target_preparer שצוין. יש הרבה מהלכי הכנה זמינים למפתחים ב-Trends Federation ואפשר להשתמש בהם כדי שהמכשיר מוגדר בצורה תקינה לפני בדיקת הביצוע.

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

מציין את מחלקת הבדיקה של Trade Federation שתשמש לביצוע הבדיקה מעביר את החבילה שבמכשיר להפעלה שהיא JUnit במקרה הזה.

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

התכונות של JUnit4

שימוש בספרייה android-support-test כהרצת הבדיקה מאפשר לאמץ פתרונות חדשים מחלקות המבחנים בסגנון JUnit4, והשינוי לדוגמה של גרביט כולל כמה מרכיבים בסיסיים מאוד לשימוש בתכונות שלו.

ניתן לגשת לקוד המקור העדכני ביותר לשינוי ה-Grit לדוגמה בכתובת: frameworks/base/packages/Shell/tests/src/com/android/shell/BugreportReceiverTest.java.

דפוסי הבדיקה הם בדרך כלל ספציפיים לצוותי הרכיבים, אבל יש כמה ודפוסי שימוש שימושיים בדרך כלל.

@SmallTest
@RunWith(AndroidJUnit4.class)
public final class FeatureFactoryImplTest {

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

בהערה @SmallTest צוין גודל בדיקה לכל כיתת הבדיקה: הכול שיטות בדיקה שנוספו לכיתת הבדיקה הזו מקבלות בירושה את ההערה של גודל הבדיקה. הגדרת הכיתה לפני הבדיקה, הסרת השיעור ואחרי הבדיקה: בדומה ל-methods setUp ו-tearDown ב-JUnit4. הערת Test משמשת לסימון הבדיקה בפועל.

    @Before
    public void setup() {
    ...
    @Test
    public void testGetProvider_shouldCacheProvider() {
    ...

ההערה @Before משמשת ב-methods של JUnit4 לביצוע הגדרה לפני בדיקה. בדוגמה הזו לא נעשה שימוש, אבל יש גם @After להפחתה לאחר בדיקה. באופן דומה, אפשר להשתמש בהערות @BeforeClass ו-@AfterClass ב methods של JUnit4 לביצוע ההגדרה לפני ביצוע כל הבדיקות בכיתת בדיקה, ומתנתק לאחר מכן. שימו לב שהשיטות להגדרה של היקף הכיתה ולפילוח שלהן חייב להיות סטטי.

בנוגע לשיטות הבדיקה, שלא כמו בגרסה הקודמת של JUnit, הן כבר לא צריכות כדי להתחיל את שם ה-method עם test, במקום זאת צריך להוסיף הערות לכל אחת מהן עם @Test. כמו תמיד, שיטות הבדיקה חייבות להיות ציבוריות, אין להצהיר על ערך החזרה לא משתמשים בפרמטרים, ועלולים לגרום חריגות.

        Context context = InstrumentationRegistry.getTargetContext();

מכיוון שהבדיקות של JUnit4 כבר לא מחייבות מחלקה בסיסית משותפת, הן כבר לא שנדרש כדי לקבל מכונות של Context דרך getContext() או getTargetContext() באמצעות methods של מחלקה בסיסית; במקום זאת, מנהל אותם באמצעות InstrumentationRegistry שבה תשתיות ההקשר והסביבה שנוצרות באמצעות מסגרת האינסטרומנטציה . בכיתה הזו אפשר גם להתקשר:

• getInstrumentation(): המופע למחלקה Instrumentation
• getArguments(): הארגומנטים בשורת הפקודה שהועברו אל am instrument דרך -e <key> <value>

פיתוח ובדיקה באופן מקומי

בתרחישי השימוש הנפוצים ביותר, אישור.

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