מקד דוגמה לאפליקציה

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

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

מדריך זה משתמש במבחן הבא כדי לשמש דוגמה:

  • מסגרות/בסיס/חבילות/מעטפת/בדיקות

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

החליטו על מיקום המקור

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

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

קובץ מניפסט

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

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

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

ניתן לגשת לגרסה העדכנית ביותר של קובץ המניפסט עבור שינוי גרריט לדוגמה בכתובת: 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 היא שם חבילת האפליקציה: זהו המזהה הייחודי שבו משתמשת מסגרת אפליקציית Android כדי לזהות אפליקציה (או בהקשר זה: אפליקציית הבדיקה שלך). כל משתמש במערכת יכול להתקין רק יישום אחד עם שם החבילה הזה.

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

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

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

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

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

android:targetPackage="com.android.shell"

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

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

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

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

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

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

ניתן לגשת לגרסה העדכנית ביותר של קובץ התצורה עבור שינוי גריט לדוגמה בכתובת: 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>

זה אומר ל- Trade Federation להתקין את ShellTests.apk על מכשיר היעד באמצעות target_preparer שצוין. ישנם מכיני יעדים רבים זמינים למפתחים ב-Trader 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, והשינוי הגריט לדוגמה מכיל שימוש בסיסי מאוד בתכונות שלו.

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

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

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

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

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

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

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

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

        Context context = InstrumentationRegistry.getTargetContext();

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

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

בנה ובדוק באופן מקומי

למקרי השימוש הנפוצים ביותר, השתמש ב-Atest .

למקרים מורכבים יותר הדורשים התאמה אישית כבדה יותר, עקוב אחר הוראות המכשור .