דפוסים נפוצים

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

בדיקה במקום יחיד

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

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

אחרי שתגדירו תוכן משלכם, תוכלו לגשת לפעילות ולמשאבים

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

דרך נפוצה להשיג זאת היא ליצור AndroidComposeTestRule באמצעות פעילות ריקה כמו ComponentActivity.

class MyComposeTest {

    @get:Rule
    val composeTestRule = createAndroidComposeRule<ComponentActivity>()

    @Test
    fun myTest() {
        // Start the app
        composeTestRule.setContent {
            MyAppTheme {
                MainScreen(uiState = exampleUiState, /*...*/)
            }
        }
        val continueLabel = composeTestRule.activity.getString(R.string.next)
        composeTestRule.onNodeWithText(continueLabel).performClick()
    }
}

לתשומת ליבך, צריך להוסיף את ComponentActivity לאפליקציה קובץ AndroidManifest.xml. כדי לאפשר זאת, מוסיפים את התלות הזאת מודול:

debugImplementation("androidx.compose.ui:ui-test-manifest:$compose_version")

מאפייני סמנטיקה בהתאמה אישית

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

// Creates a semantics property of type Long.
val PickedDateKey = SemanticsPropertyKey<Long>("PickedDate")
var SemanticsPropertyReceiver.pickedDate by PickedDateKey

עכשיו צריך להשתמש במאפיין הזה בתכונת הצירוף semantics:

val datePickerValue by remember { mutableStateOf(0L) }
MyCustomDatePicker(
    modifier = Modifier.semantics { pickedDate = datePickerValue }
)

מהבדיקות, צריך להשתמש ב-SemanticsMatcher.expectValue כדי להצהיר על הערך של נכס:

composeTestRule
    .onNode(SemanticsMatcher.expectValue(PickedDateKey, 1445378400)) // 2015-10-21
    .assertExists()

אימות של שחזור המצב

יש לוודא שמצב רכיבי ה-Composes ישוחזר כראוי כאשר צריך ליצור מחדש את הפעילות או התהליך. בצעו בדיקות כאלה בלי להסתמך על פעילות פנאי עם הכיתה StateRestorationTester.

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


class MyStateRestorationTests {

    @get:Rule
    val composeTestRule = createComposeRule()

    @Test
    fun onRecreation_stateIsRestored() {
        val restorationTester = StateRestorationTester(composeTestRule)

        restorationTester.setContent { MainScreen() }

        // TODO: Run actions that modify the state

        // Trigger a recreation
        restorationTester.emulateSavedInstanceStateRestore()

        // TODO: Verify that state has been correctly restored.
    }
}

בדיקה של הגדרות מכשיר שונות

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

DeviceConfigurationOverride הוא API לבדיקה בלבד שמאפשר לדמות תצורות מכשיר שונות באופן מותאם לשוק המקומי עבור התוכן של @Composable בבדיקה.

לאובייקט הנלווה של DeviceConfigurationOverride יש את הדברים הבאים פונקציות תוסף, שעוקפות את מאפייני ההגדרות האישיות ברמת המכשיר:

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

לדוגמה, הקוד הבא מיישם את שינוי של DeviceConfigurationOverride.ForcedSize() לשינוי הצפיפות באופן מקומי, ולאלץ את התוכן הקומפוזבילי MyScreen להיות מוצג בסביבה גדולה גם אם המכשיר שבו מתבצעת הבדיקה לא תומך בחלון הזה גודל ישיר:

composeTestRule.setContent {
    DeviceConfigurationOverride(
        DeviceConfigurationOverride.ForcedSize(DpSize(1280.dp, 800.dp))
    ) {
        MyScreen() // will be rendered in the space for 1280dp by 800dp without clipping
    }
}

כדי להחיל כמה שינויים מברירת המחדל יחד, צריך להשתמש DeviceConfigurationOverride.then()

composeTestRule.setContent {
    DeviceConfigurationOverride(
        DeviceConfigurationOverride.FontScale(1.5f) then
            DeviceConfigurationOverride.FontWeightAdjustment(200)
    ) {
        Text(text = "text with increased scale and weight")
    }
}

משאבים נוספים

  • אפליקציות בדיקה ב-Android: הכלי העיקרי לבדיקת Android דף הנחיתה כולל מבט מקיף על העקרונות והטכניקות של הבדיקה.
  • יסודות הבדיקה: מידע נוסף על המושגים המרכזיים של בדיקת אפליקציה ל-Android.
  • בדיקות מקומיות: אפשר להריץ כמה בדיקות באופן מקומי, בתחנת עבודה משלך.
  • בדיקות אינסטרומנטליות: זה טוב להריץ גם בדיקות אינסטרומנטליות. כלומר, בדיקות שמריצים באופן ישיר במכשיר.
  • אינטגרציה רציפה (CI): אינטגרציה רציפה (CI) מאפשרת לשלב את הבדיקות בפריסה צינור עיבוד נתונים.
  • בדיקה של גדלים שונים של מסכים: באמצעות כמה מכשירים רבים שזמינים למשתמשים, צריך לבדוק מסכים שונים בגדלים שונים.
  • Espresso: מיועדת לשימוש שמבוסס על תצוגה עם ממשקי משתמש, הידע של אספרסו עדיין יכול לעזור בהיבטים מסוימים של 'פיתוח נייטיב' בדיקה.