AndroidJUnitRunner

הכיתה AndroidJUnitRunner היא מפעילת בדיקות של JUnit שמאפשרת להריץ בדיקות JUnit 4 עם מכשירי Android, כולל בדיקות שמשתמשות במסגרות הבדיקה Espresso,‏ UI Automator ו-Compose.

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

הכלי הזה תומך בכמה משימות בדיקה נפוצות, כולל:

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

כתיבת בדיקות JUnit

קטע הקוד הבא מראה איך אפשר לכתוב בדיקת JUnit 4 עם מכשירי מדידה כדי לאמת שהפעולה changeText בכיתה ChangeTextBehavior פועלת כמו שצריך:

@RunWith(AndroidJUnit4::class)
@LargeTest // Optional runner annotation
class ChangeTextBehaviorTest {
 val stringToBeTyped = "Espresso"
 // ActivityTestRule accesses context through the runner
 @get:Rule
 val activityRule = ActivityTestRule(MainActivity::class.java)

 @Test fun changeText_sameActivity() {
 // Type text and then press the button.
 onView(withId(R.id.editTextUserInput))
 .perform(typeText(stringToBeTyped), closeSoftKeyboard())
 onView(withId(R.id.changeTextBt)).perform(click())

 // Check that the text was changed.
 onView(withId(R.id.textToBeChanged))
 .check(matches(withText(stringToBeTyped)))
 }
}

@RunWith(AndroidJUnit4.class)
@LargeTest // Optional runner annotation
public class ChangeTextBehaviorTest {

    private static final String stringToBeTyped = "Espresso";

    @Rule
    public ActivityTestRule<MainActivity>; activityRule =
            new ActivityTestRule<>;(MainActivity.class);

    @Test
    public void changeText_sameActivity() {
        // Type text and then press the button.
        onView(withId(R.id.editTextUserInput))
                .perform(typeText(stringToBeTyped), closeSoftKeyboard());
        onView(withId(R.id.changeTextBt)).perform(click());

        // Check that the text was changed.
        onView(withId(R.id.textToBeChanged))
                .check(matches(withText(stringToBeTyped)));
    }
}

גישה להקשר של האפליקציה

כשמשתמשים ב-AndroidJUnitRunner כדי להריץ את הבדיקות, אפשר לגשת להקשר של האפליקציה שנבדקת על ידי קריאה ל-method הסטטי ApplicationProvider.getApplicationContext(). אם יצרתם תת-סוג מותאם אישית של Application באפליקציה, השיטה הזו מחזירה את ההקשר של תת-הסוג המותאם אישית.

אם אתם מטמיעים כלים, אתם יכולים לגשת ל-API לבדיקות ברמה נמוכה באמצעות הכיתה InstrumentationRegistry. הכיתה הזו כוללת את האובייקט Instrumentation, את האובייקט של אפליקציית היעד Context, את האובייקט של אפליקציית הבדיקה Context ואת הארגומנטים של שורת הפקודה שהועברו לבדיקה.

סינון בדיקות

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

• @RequiresDevice: קובע שהבדיקה צריכה לפעול רק במכשירים פיזיים, ולא באמולטורים.
• @SdkSuppress: עיכוב ההרצה של הבדיקה ברמה נמוכה יותר של Android API מאשר הרמה שצוינה. לדוגמה, כדי למנוע את הפעלת הבדיקות בכל רמות ה-API שמתחת לרמה 23, משתמשים בהערה @SDKSuppress(minSdkVersion=23).
• @SmallTest,‏ @MediumTest ו-@LargeTest: סיווג משך הזמן שבו צריך להריץ את הבדיקה, וכתוצאה מכך, תדירות ההרצה של הבדיקה. אפשר להשתמש בהערה הזו כדי לסנן את הבדיקות שרוצים להריץ, על ידי הגדרת המאפיין android.testInstrumentationRunnerArguments.size:

-Pandroid.testInstrumentationRunnerArguments.size=small

בדיקות של שרידי נתונים

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

לדוגמה, כדי לפצל את חבילת הבדיקות ל-10 פלחים ולהריץ רק את הבדיקות שמקובצות בפלח השני, משתמשים בפקודת adb הבאה:

adb shell am instrument -w -e numShards 10 -e shardIndex 2

שימוש בתזמור בדיקות ל-Android

Android Test Orchestrator מאפשר להריץ כל בדיקה של האפליקציה בקריאה משלה ל-Instrumentation. כשמשתמשים ב-AndroidJUnitRunner בגרסה 1.0 ואילך, יש לכם גישה ל-Android Test Orchestrator.

תזמור הבדיקות ל-Android מציע את היתרונות הבאים לסביבת הבדיקה:

• מצב משותף מינימלי: כל בדיקה פועלת במכונה משלה של Instrumentation. לכן, אם הבדיקה משתפת את מצב האפליקציה, רוב המצב המשותף הזה מוסר מהמעבד או מהזיכרון של המכשיר אחרי כל בדיקה. כדי להסיר את כל המצבים המשותפים מהמעבד והזיכרון של המכשיר אחרי כל בדיקה, משתמשים בדגל clearPackageData. דוגמה מופיעה בקטע הפעלה מ-Gradle.
• קריסות הן מבודדות: גם אם בדיקה אחת קורסת, היא גורמת לקריסה רק של המכונה שלה ב-Instrumentation. כלומר, שאר הבדיקות בחבילה עדיין יפעלו ויספקו תוצאות בדיקה מלאות.

הבידוד הזה עלול להוביל להארכה של זמן ביצוע הבדיקה, כי Android Test Orchestrator מפעיל מחדש את האפליקציה אחרי כל בדיקה.

Android Test Orchestrator מותקן מראש ב-Android Studio וב-Firebase Test Lab, אבל צריך להפעיל את התכונה ב-Android Studio.

הפעלה מ-Gradle

כדי להפעיל את Android Test Orchestrator באמצעות כלי שורת הפקודה של Gradle, מבצעים את השלבים הבאים:

• שלב 1: משנים את קובץ ה-gradle. מוסיפים את ההצהרות הבאות לקובץ build.gradle של הפרויקט:

android {
 defaultConfig {
  ...
  testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"

  // The following argument makes the Android Test Orchestrator run its
  // "pm clear" command after each test invocation. This command ensures
  // that the app's state is completely cleared between tests.
  testInstrumentationRunnerArguments clearPackageData: 'true'
 }

 testOptions {
  execution 'ANDROIDX_TEST_ORCHESTRATOR'
 }
}

dependencies {
 androidTestImplementation 'androidx.test:runner:1.1.0'
 androidTestUtil 'androidx.test:orchestrator:1.1.0'
}

• שלב 2: מריצים את Android Test Orchestrator באמצעות הפקודה הבאה:

./gradlew connectedCheck

הפעלה מ-Android Studio

כדי להפעיל את Android Test Orchestrator ב-Android Studio, מוסיפים את ההצהרות שמפורטות בקטע הפעלה מ-Gradle לקובץ build.gradle של האפליקציה.

הפעלה משורת הפקודה

כדי להשתמש ב-Android Test Orchestrator בשורת הפקודה, מריצים את הפקודות הבאות בחלון מסוף:

DEVICE_API_LEVEL=$(adb shell getprop ro.build.version.sdk)

FORCE_QUERYABLE_OPTION=""
if [[ $DEVICE_API_LEVEL -ge 30 ]]; then
   FORCE_QUERYABLE_OPTION="--force-queryable"
fi

# uninstall old versions
adb uninstall androidx.test.services
adb uninstall androidx.test.orchestrator

# Install the test orchestrator.
adb install $FORCE_QUERYABLE_OPTION -r path/to/m2repository/androidx/test/orchestrator/1.4.2/orchestrator-1.4.2.apk

# Install test services.
adb install $FORCE_QUERYABLE_OPTION -r path/to/m2repository/androidx/test/services/test-services/1.4.2/test-services-1.4.2.apk

# Replace "com.example.test" with the name of the package containing your tests.
# Add "-e clearPackageData true" to clear your app's data in between runs.
adb shell 'CLASSPATH=$(pm path androidx.test.services) app_process / \
 androidx.test.services.shellexecutor.ShellMain am instrument -w -e \
 targetInstrumentation com.example.test/androidx.test.runner.AndroidJUnitRunner \
 androidx.test.orchestrator/.AndroidTestOrchestrator'

כפי שרואים בסינטקס של הפקודה, מתקינים את Android Test Orchestrator ואז משתמשים בו ישירות.

adb shell pm list instrumentation

שימוש בסביבות פיתוח שונות

אם אתם משתמשים בכלי עיבוד נתונים אחר כדי לבדוק את האפליקציה, עדיין תוכלו להשתמש ב-Android Test Orchestrator. לשם כך, עליכם לבצע את השלבים הבאים:

1. כוללים את החבילות הנדרשות בקובץ ה-build של האפליקציה.
2. מפעילים את Android Test Orchestrator משורת הפקודה.

ארכיטקטורה

קובץ ה-APK של שירות Orchestrator מאוחסן בתהליך נפרד מקובץ ה-APK לבדיקה ומקובץ ה-APK של האפליקציה שנבדקת:

Android Test Orchestrator אוסף בדיקות JUnit בתחילת ההרצה של חבילת הבדיקות, אבל לאחר מכן הוא מבצע כל בדיקה בנפרד, במכונה משלה של Instrumentation.

מידע נוסף

מידע נוסף על השימוש ב-AndroidJUnitRunner זמין במאמר העזרה בנושא API.

מקורות מידע נוספים

למידע נוסף על השימוש ב-AndroidJUnitRunner, אפשר לעיין במקורות המידע הבאים.

דוגמיות

• AndroidJunitRunnerSample: הדגמה של הערות לבדיקות, בדיקות עם פרמטרים ויצירת חבילות בדיקות.