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

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

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

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

• frameworks/base/packages/Shell/tests

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

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

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

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

קובץ מניפסט

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

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

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

הגרסה האחרונה של קובץ המניפסט לשינוי לדוגמה ב-Gerrit זמינה בכתובת: 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, המסגרת מפעילה מחדש את התהליך com.android.shell ומחדירה לתוכו את קוד האינסטרומנטציה לצורך ביצוע הבדיקה. משמעות הדבר היא גם שקוד הבדיקה גישה לכל המכונות של הכיתה שרצות באפליקציה בבדיקה, היכולת לשנות את המצב תלויה בקולי הבדיקה שנחשפים.

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

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

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

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

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

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

צירפנו כאן קובץ snapshot לנוחותכם:

<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>

הפקודה הזו מורה ל-Trade 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 שתשמש להרצת הבדיקה, והיא מעבירה את החבילה במכשיר להרצה ואת מסגרת ה-test runner, שהיא JUnit במקרה הזה.

מידע נוסף על הגדרות מודול לבדיקה

התכונות של JUnit4

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

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

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

@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 משמשת את השיטות של JUnit4 כדי לבצע הגדרה לפני הבדיקה. בדוגמה הזו לא נעשה שימוש, אבל יש גם @After להפחתה לאחר בדיקה. באופן דומה, אפשר להשתמש בהערות @BeforeClass ו-@AfterClass בשיטות של JUnit4 כדי לבצע הגדרה לפני שמריצים את כל הבדיקות בכיתה לבדיקה, ואז לבצע ניתוק. שימו לב שהשיטות להגדרה של היקף הכיתה ולפילוח שלהן חייב להיות סטטי.

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

        Context context = InstrumentationRegistry.getTargetContext();

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

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

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

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

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