Typowe wzorce

Możesz ją testować za pomocą dobrze znanych metod i wzorców.

Testuj w izolacji

ComposeTestRule pozwala rozpocząć aktywność wyświetlającą dowolny element kompozycyjny: pełna aplikacja, pojedynczy ekran lub mały element. Warto też sprawdzić, czy elementy kompozycyjne są poprawnie zapisane i czy działają niezależnie, co ułatwia testowanie interfejsu.

Nie oznacza to, że testy interfejsu jednostki należy tworzyć tylko. Bardzo ważne są też testy interfejsu, określające większe obszary interfejsu.

Uzyskuj dostęp do aktywności i zasobów po ustawieniu własnych treści

Często trzeba skonfigurować testowaną treść za pomocą funkcji composeTestRule.setContent oraz uzyskać dostęp do zasobów związanych z aktywnością, na przykład aby stwierdzić, że wyświetlany tekst pasuje do zasobu w postaci ciągu znaków. Nie możesz jednak wywołać funkcji setContent w regule utworzonej za pomocą createAndroidComposeRule(), jeśli aktywność już ją wywołuje.

Częstym wzorcem jest utworzenie AndroidComposeTestRule przy użyciu pustej aktywności, np. 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()
    }
}

Pamiętaj, że do pliku AndroidManifest.xml aplikacji musisz dodać parametr ComponentActivity. Aby to zrobić, dodaj tę zależność do modułu:

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

Niestandardowe właściwości semantyki

Możesz tworzyć niestandardowe właściwości semantyki, aby udostępniać informacje testom. Aby to zrobić, zdefiniuj nowy obiekt SemanticsPropertyKey i udostępnij go za pomocą SemanticsPropertyReceiver.

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

Teraz użyj tej właściwości w modyfikatorze semantics:

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

Na podstawie testów użyj narzędzia SemanticsMatcher.expectValue, aby potwierdzić wartość właściwości:

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

Ostrzeżenie: niestandardowych właściwości semantycznych należy używać tylko wtedy, gdy za pomocą podanych mechanizmów wyszukiwania i dopasowania trudno jest dopasować konkretny element. Nie zalecamy używania niestandardowych właściwości semantycznych do ujawniania właściwości wizualnych, takich jak kolory, rozmiar czcionki lub zaokrąglony promień narożnika, ponieważ może to zanieczyszczać kod produkcyjny, a nieprawidłowe implementacje mogą prowadzić do błędów, które są trudne do znalezienia.

Sprawdź przywrócenie stanu

Sprawdź, czy stan elementów Compose jest prawidłowo przywracany po odtworzeniu aktywności lub procesu. Przeprowadzaj takie kontrole bez ponownego odtwarzania aktywności za pomocą klasy StateRestorationTester.

W ramach tych zajęć można przeprowadzić symulację odtworzenia funkcji kompozycyjnej. Szczególnie przydatna jest weryfikacja implementacji 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.
    }
}

Testowanie różnych konfiguracji urządzeń

Aplikacje na Androida muszą dostosowywać się do wielu zmieniających się warunków, takich jak rozmiary okien, ustawienia regionalne, rozmiary czcionek, ciemne i jasne motywy. Większość tych warunków pochodzi z wartości na poziomie urządzenia kontrolowanych przez użytkownika i pojawiających się w bieżącej instancji Configuration. Testowanie różnych konfiguracji bezpośrednio w teście jest trudne, ponieważ trzeba w nim skonfigurować właściwości na poziomie urządzenia.

DeviceConfigurationOverride to interfejs API przeznaczony tylko do testów, który umożliwia symulowanie różnych konfiguracji urządzeń na potrzeby testowanej treści @Composable.

Uwaga: dostępność DeviceConfigurationOverride jest dostępna w momencie tworzenia wiadomości 1.7.0-alpha03

Obiekt towarzyszący obiektu DeviceConfigurationOverride ma te funkcje rozszerzenia, które zastępują właściwości konfiguracji na poziomie urządzenia:

• DeviceConfigurationOverride.DarkMode(): zastępuje w systemie ciemny lub jasny motyw.
• DeviceConfigurationOverride.FontScale(): zastępuje systemową skalę czcionek.
• DeviceConfigurationOverride.FontWeightAdjustment(): zastępuje systemowe dostosowanie grubości czcionki.
• DeviceConfigurationOverride.ForcedSize(): wymusza określoną ilość miejsca niezależnie od rozmiaru urządzenia.
• DeviceConfigurationOverride.LayoutDirection(): zastępuje kierunek układu (od lewej do prawej lub od prawej do lewej).
• DeviceConfigurationOverride.Locales(): zastępuje język.
• DeviceConfigurationOverride.RoundScreen(): zastępuje, gdy ekran jest zaokrąglony.

Aby zastosować określone zastąpienie, zapakuj testowaną treść w wywołaniu funkcji najwyższego poziomu DeviceConfigurationOverride(), przekazując zastąpienie, które zostanie zastosowane jako parametr.

Na przykład ten kod stosuje zastąpienie DeviceConfigurationOverride.ForcedSize(), aby lokalnie zmienić gęstość, wymuszając renderowanie funkcji MyScreen kompozycyjnej w dużym oknie poziomym, nawet jeśli urządzenie, na którym testujesz test, nie obsługuje bezpośrednio tego rozmiaru okna:

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

Aby zastosować kilka zastąpień jednocześnie, użyj funkcji DeviceConfigurationOverride.then():

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

Dodatkowe materiały

• Testowanie aplikacji na Androida: główna strona docelowa testowania aplikacji na Androida zapewnia szerszy wgląd w podstawy i techniki testowania.
• Podstawy testowania: dowiedz się więcej o podstawowych pojęciach związanych z testowaniem aplikacji na Androida.
• Testy lokalne: niektóre testy możesz przeprowadzić lokalnie na własnej stacji roboczej.
• Testy z instrumentacją: warto też przeprowadzać testy z użyciem instrumentów. Oznacza to, że testy przeprowadzane bezpośrednio na urządzeniu.
• Tryb ciągłej integracji: tryb ciągłej integracji umożliwia integrację testów z potokiem wdrożenia.
• Testowanie różnych rozmiarów ekranu: użytkownicy mają do dyspozycji wiele urządzeń, dlatego warto przetestować różne rozmiary ekranów.
• Espresso: to narzędzie jest przeznaczone dla użytkowników korzystających z widoku danych, ale wiedza o espresso może być pomocna w niektórych aspektach testowania funkcji Compose.