Häufige Muster

Sie können die Compose-Anwendung mit bewährten Ansätzen und Mustern testen.

Isolierend testen

Mit ComposeTestRule können Sie eine Aktivität starten, in der jede zusammensetzbare Funktion angezeigt wird: Ihre vollständige Anwendung, ein einzelner Bildschirm oder ein kleines Element. Es empfiehlt sich auch, zu prüfen, ob die zusammensetzbaren Funktionen richtig gekapselt sind und unabhängig voneinander funktionieren. Dies ermöglicht einfachere und zielgerichtetere Tests der Benutzeroberfläche.

Das bedeutet nicht, dass Sie nur UI-Tests für Einheiten erstellen sollten. UI-Tests, die größere Bereiche Ihrer UI abdecken, sind ebenfalls sehr wichtig.

Nachdem du deine eigenen Inhalte festgelegt hast, kannst du auf die Aktivität und Ressourcen zugreifen

Oft müssen Sie den zu testenden Inhalt mit composeTestRule.setContent festlegen und auch auf Aktivitätsressourcen zugreifen, um beispielsweise zu bestätigen, dass ein angezeigter Text mit einer String-Ressource übereinstimmt. Sie können setContent jedoch nicht für eine Regel aufrufen, die mit createAndroidComposeRule() erstellt wurde, wenn sie von der Aktivität bereits aufgerufen wird.

Dazu wird häufig ein AndroidComposeTestRule mit einer leeren Aktivität wie ComponentActivity erstellt.

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()
    }
}

Beachten Sie, dass ComponentActivity der Datei AndroidManifest.xml Ihrer App hinzugefügt werden muss. Aktivieren Sie dies, indem Sie Ihrem Modul diese Abhängigkeit hinzufügen:

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

Benutzerdefinierte Semantik-Attribute

Sie können benutzerdefinierte Semantik-Attribute erstellen, um Informationen für Tests verfügbar zu machen. Definieren Sie dazu eine neue SemanticsPropertyKey und stellen Sie sie mithilfe von SemanticsPropertyReceiver zur Verfügung.

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

Verwende diese Eigenschaft jetzt im semantics-Modifikator:

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

Verwenden Sie in Tests SemanticsMatcher.expectValue, um den Wert des Attributs zu bestätigen:

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

Warnung :Sie sollten benutzerdefinierte Semantik-Properties nur dann verwenden, wenn es schwierig ist, ein bestimmtes Element mithilfe der jeweiligen Sucher und Abgleicher zuzuordnen. Die Verwendung benutzerdefinierter Semantikeigenschaften zur Darstellung visueller Eigenschaften wie Farben, Schriftgröße oder abgerundeter Ecken wird nicht empfohlen, da dies den Produktionscode beeinträchtigen und falsche Implementierungen zu schwer auffindbaren Fehlern führen kann.

Wiederherstellung des Status prüfen

Prüfen Sie, ob der Status der Compose-Elemente korrekt wiederhergestellt wird, wenn die Aktivität oder der Prozess neu erstellt wird. Führen Sie solche Prüfungen durch, ohne sich auf die Neuerstellung von Aktivitäten mit der Klasse StateRestorationTester zu verlassen.

Mit dieser Klasse können Sie die Neuerstellung einer zusammensetzbaren Funktion simulieren. Besonders nützlich ist es, die Implementierung von rememberSaveable zu prüfen.

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

Verschiedene Gerätekonfigurationen testen

Android-Apps müssen sich an viele sich ändernde Bedingungen anpassen, z. B. Fenstergrößen, Spracheinstellungen, Schriftgrößen sowie dunkle und helle Designs. Die meisten dieser Bedingungen werden von Werten auf Geräteebene abgeleitet, die vom Nutzer gesteuert und mit der aktuellen Configuration-Instanz bereitgestellt werden. Es ist schwierig, verschiedene Konfigurationen direkt in einem Test zu testen, da im Test Eigenschaften auf Geräteebene konfiguriert werden müssen.

DeviceConfigurationOverride ist eine reine Test-API, mit der du verschiedene Gerätekonfigurationen für den zu testenden @Composable-Inhalt lokalisiert simulieren kannst.

Hinweis: DeviceConfigurationOverride ist ab „Schreiben“ verfügbar. 1.7.0-alpha03

Das Companion-Objekt von DeviceConfigurationOverride hat die folgenden Erweiterungsfunktionen, die die Konfigurationseigenschaften auf Geräteebene überschreiben:

• DeviceConfigurationOverride.DarkMode(): Setzt das System auf das dunkle oder helle Design um.
• DeviceConfigurationOverride.FontScale(): Überschreibt die Systemschriftgröße.
• DeviceConfigurationOverride.FontWeightAdjustment(): Überschreibt die Anpassung der Systemschriftstärke.
• DeviceConfigurationOverride.ForcedSize(): Erzwingt unabhängig von der Gerätegröße eine bestimmte Speicherplatzmenge.
• DeviceConfigurationOverride.LayoutDirection(): überschreibt die Layoutrichtung (von links nach rechts oder von rechts nach links).
• DeviceConfigurationOverride.Locales(): überschreibt die Sprache.
• DeviceConfigurationOverride.RoundScreen(): Wird überschrieben, wenn der Bildschirm rund ist.

Um eine bestimmte Überschreibung anzuwenden, fassen Sie den zu testenden Inhalt in einen Aufruf der obersten Ebene DeviceConfigurationOverride() ein und übergeben Sie die Überschreibung als Parameter, um sie anzuwenden.

Der folgende Code wendet beispielsweise die Überschreibung DeviceConfigurationOverride.ForcedSize() an, um die Dichte lokal zu ändern. Dadurch wird die zusammensetzbare Funktion MyScreen in einem großen Querformatfenster gerendert, selbst wenn das Gerät, auf dem der Test ausgeführt wird, diese Fenstergröße nicht direkt unterstützt:

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

Verwenden Sie DeviceConfigurationOverride.then(), um mehrere Überschreibungen gleichzeitig anzuwenden:

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

Weitere Ressourcen

• Test-Apps unter Android: Die Haupt-Landingpage für Android-Tests bietet einen umfassenderen Überblick über die Grundlagen und Techniken von Tests.
• Grundlagen des Testens:Weitere Informationen zu den Kernkonzepten des Testens einer Android-App.
• Lokale Tests:Sie können einige Tests lokal auf Ihrer eigenen Workstation ausführen.
• Instrumentierte Tests:Es empfiehlt sich, auch instrumentierte Tests durchzuführen. Das sind Tests, die direkt auf dem Gerät ausgeführt werden.
• Continuous Integration: Mit Continuous Integration können Sie Ihre Tests in Ihre Bereitstellungspipeline einbinden.
• Testen Sie verschiedene Bildschirmgrößen:Da Nutzer auf vielen Geräten zur Verfügung stehen, sollten Sie Tests für unterschiedliche Bildschirmgrößen durchführen.
• Espresso: Diese Espresso-Kenntnisse sind zwar für ansichtsbasierte UIs vorgesehen, können aber für einige Aspekte von Compose-Tests hilfreich sein.