מיקוד דוגמה ליישום

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

שים לב שהמדריך הזה מניח שכבר יש לך ידע מסוים בזרימת העבודה של עץ המקור של הפלטפורמה. אם לא, עיין בכתובת https://source.android.com/source/requirements. הדוגמה המכוסה כאן היא כתיבת מבחן מכשור חדש עם חבילת יעד מוגדרת בחבילת יישום בדיקה משלה. אם אינך מכיר את המושג, אנא קרא את המבוא לבדיקת פלטפורמה .

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

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

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

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

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

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

קובץ מניפסט

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

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

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

ניתן לגשת לגרסה העדכנית ביותר של קובץ המניפסט עבור שינוי גרריט לדוגמה בכתובת: https://android.googlesource.com/platform/frameworks/base/+/master/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 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 ציינה גודל בדיקה עבור מחלקת הבדיקה כולה: כל שיטות הבדיקה שנוספו למחלקת בדיקה זו יורשות ביאור גודל בדיקה זה. הגדרת מחלקה לפני מבחן, פירוק מחלקה לאחר מבחן, ופריקת מחלקה לאחר מבחן: בדומה לשיטות tearDown setUp 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 .

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