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

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

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

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

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

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

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

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

ראה עוד דיונים על מקור מיקום למשל מקצה לקצה עבור בדיקות instrumenting עצמיות .

קובץ מניפסט

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

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

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

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

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

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

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

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

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

android:targetPackage="com.android.shell"

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

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

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

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

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

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

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

<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

תכונות JUnit4

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

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

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