Häufige Muster

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

Im Isolationstest

Mit ComposeTestRule können Sie eine Aktivität starten, in der ein beliebiges Composeable angezeigt wird: Ihre gesamte Anwendung, ein einzelner Bildschirm oder ein kleines Element. Außerdem sollten Sie prüfen, ob Ihre Composeables korrekt gekapselt sind und unabhängig funktionieren. So lassen sich die UI-Tests einfacher und gezielter durchführen.

Das bedeutet nicht, dass Sie nur UI-Unittests erstellen sollten. UI-Tests, die größere Teile Ihrer Benutzeroberfläche umfassen, sind ebenfalls sehr wichtig.

Nach dem Festlegen eigener Inhalte auf Aktivitäten und Ressourcen zugreifen

Oft müssen Sie den zu testenden Inhalt mit composeTestRule.setContent festlegen und auch auf Aktivitätsressourcen zugreifen, z. B. um zu prüfen, ob ein angezeigter Text mit einer Stringressource übereinstimmt. Sie können setContent jedoch nicht für eine Regel aufrufen, die mit createAndroidComposeRule() erstellt wurde, wenn die Aktivität sie bereits aufruft.

Ein gängiges Muster hierfür ist die Erstellung einer AndroidComposeTestRule mit einer leeren Aktivität wie 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 muss der Datei AndroidManifest.xml Ihrer App hinzugefügt werden. Aktivieren Sie diese Funktion, indem Sie Ihrem Modul diese Abhängigkeit hinzufügen:

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

Benutzerdefinierte semantische Eigenschaften

Sie können benutzerdefinierte Semantikeigenschaften erstellen, um Informationen für Tests freizugeben. Definieren Sie dazu eine neue SemanticsPropertyKey und stellen Sie sie mithilfe der SemanticsPropertyReceiver zur Verfügung.

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

Verwende diese Property 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 der Property zu prüfen:

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

Wiederherstellung des Status prüfen

Prüfen Sie, ob der Status Ihrer 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 Wiederherstellung von Aktivitäten mit der Klasse StateRestorationTester zu verlassen.

In dieser Klasse können Sie die Neuerstellung eines Composeables simulieren. Das ist besonders nützlich, um die Implementierung von rememberSaveable zu überprü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: Fenstergrößen, Sprachen, Schriftgrößen, dunkle und helle Designs usw. Die meisten dieser Bedingungen werden aus Werten auf Geräteebene abgeleitet, die vom Nutzer gesteuert und mit der aktuellen Configuration-Instanz freigegeben werden. Es ist schwierig, verschiedene Konfigurationen direkt in einem Test zu testen, da der Test Eigenschaften auf Geräteebene konfigurieren muss.

DeviceConfigurationOverride ist eine API nur zum Testen, mit der du für die zu testenden @Composable-Inhalte lokal verschiedene Gerätekonfigurationen simulieren kannst.

Das zugehörige Objekt von DeviceConfigurationOverride hat die folgenden Erweiterungsfunktionen, die Konfigurationseigenschaften auf Geräteebene überschreiben:

Wenn Sie eine bestimmte Überschreibung anwenden möchten, schließen Sie die zu testenden Inhalte in einen Aufruf der obersten Funktion DeviceConfigurationOverride() ein und übergeben Sie die Überschreibung als Parameter.

Im folgenden Code wird beispielsweise die DeviceConfigurationOverride.ForcedSize()-Überschreibung angewendet, um die Dichte lokal zu ändern. Dadurch wird das MyScreen-Komposit in einem großen Querformatfenster gerendert, auch 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

Wenn Sie mehrere Überschreibungen gleichzeitig anwenden möchten, verwenden Sie DeviceConfigurationOverride.then():

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

Zusätzliche Ressourcen

  • Apps unter Android testen: Die Haupt-Landingpage für Android-Tests bietet einen umfassenderen Überblick über die Grundlagen und Techniken des Testens.
  • Grundlagen des Testens:Hier erfahren Sie mehr über die grundlegenden Konzepte beim Testen einer Android-App.
  • Lokale Tests:Einige Tests können Sie lokal auf Ihrer eigenen Workstation ausführen.
  • Instrumentierte Tests:Es empfiehlt sich, auch instrumentierte Tests auszufü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.
  • Verschiedene Bildschirmgrößen testen:Da Nutzern eine Vielzahl von Geräten zur Verfügung steht, sollten Sie verschiedene Bildschirmgrößen testen.
  • Espresso: Obwohl Espresso für viewbasierte UIs gedacht ist, können Kenntnisse zu Espresso für einige Aspekte von Compose-Tests hilfreich sein.