גוגל מחויבת לקדם הון גזעי עבור קהילות שחורות. תראה איך.
דף זה תורגם על ידי Cloud Translation API.
Switch to English

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

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

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

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

  • מסגרות / בסיס / חבילות / מעטפת / מבחנים

מומלץ לדפדף בקוד תחילה כדי להתרשם גס לפני שתמשיך.

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

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

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

קובץ מניפסט

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

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

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

ניתן לגשת לגרסה האחרונה של קובץ המניפסט לשינוי גרט המדגם בכתובת: 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" />
 

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

 android:targetPackage="com.android.shell"
 

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

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

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

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

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

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

ניתן לגשת לגרסה האחרונה של קובץ ה- config לשינוי גרט המדגם ב: מסגרות / בסיס / חבילות / מעטפת / בדיקות / 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>
 

זה אומר לפדרציית המסחר להתקין את ShellTests.apk על מכשיר היעד באמצעות יעד_מכונן שצוין. ישנם מכשירי יעד רבים העומדים לרשות המפתחים בפדרציית הסחר וניתן להשתמש בהם כדי להבטיח שההתקנה התקינה כראוי לפני ביצוע הבדיקה.

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

זה מציין את מחלקת הבדיקות של התאחדות המסחר שתשמש לביצוע הבדיקה ועוברים בחבילה במכשיר המיועד לביצוע ואת מסגרת רץ הבדיקה שהיא JUnit במקרה זה.

חפש כאן למידע נוסף על Configs Module Test

תכונות JUnit4

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

ניתן לגשת לקוד המקור האחרון לשינוי גרט המדגם ב: מסגרות / בסיס / חבילות / מעטפת / בדיקות / src / com / אנדרואיד / מעטפת / BugreportReceiverTest.java

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

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

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

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

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

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

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

         Context context = InstrumentationRegistry.getTargetContext();
 

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

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

בנה ובחן מקומי

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

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