Häufige Muster

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

Isoliert testen

Mit ComposeTestRule können Sie eine Aktivität starten, in der ein beliebiges Composable angezeigt wird: Ihre gesamte Anwendung, ein einzelner Bildschirm oder ein kleines Element. Außerdem ist es ratsam, darauf zu achten, dass Ihre Composables richtig gekapselt sind und unabhängig voneinander funktionieren. So lassen sich UI-Tests einfacher und gezielter durchführen.

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

Nachdem Sie eigene Inhalte festgelegt haben, können Sie auf die Aktivität und die Ressourcen zugreifen.

Häufig müssen Sie den zu testenden Inhalt mit composeTestRule.setContent festlegen und auf Aktivitätsressourcen zugreifen, um beispielsweise zu prüfen, ob ein angezeigter Text mit einer String-Ressource übereinstimmt. Sie können setContent jedoch nicht für eine mit createAndroidComposeRule() erstellte Regel aufrufen, wenn sie bereits von der Aktivität aufgerufen wird.

Ein gängiges Muster hierfür ist das Erstellen eines 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()
    }
}

Beachten Sie, dass ComponentActivity der Datei AndroidManifest.xml Ihrer App hinzugefügt werden muss. Fügen Sie dazu Ihrem Modul die folgende Abhängigkeit hinzu:

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

Benutzerdefinierte semantische Eigenschaften

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

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

Verwenden Sie diese Property jetzt im Modifikator semantics:

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

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

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

Statuswiederherstellung 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 Neuerstellung von Aktivitäten mit der Klasse StateRestorationTester zu verlassen.

Mit dieser Klasse können Sie die Neuerstellung eines Composables 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, z. B. Fenstergrößen, Sprachen, Schriftgrößen, dunkle und helle Designs. Die meisten dieser Bedingungen werden aus Werten auf Geräteebene abgeleitet, die vom Nutzer gesteuert und mit der aktuellen Configuration-Instanz bereitgestellt werden. Das Testen verschiedener Konfigurationen direkt in einem Test ist schwierig, da im Test Eigenschaften auf Geräteebene konfiguriert werden müssen.

DeviceConfigurationOverride ist eine API, die nur für Tests verwendet werden kann. Mit ihr lassen sich verschiedene Gerätekonfigurationen lokal für die zu testenden @Composable-Inhalte simulieren.

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

Wenn Sie eine bestimmte Überschreibung anwenden möchten, umschließen Sie den zu testenden Inhalt mit einem Aufruf der Funktion der obersten Ebene DeviceConfigurationOverride() und übergeben Sie die anzuwendende Überschreibung als Parameter.

Im folgenden Code wird beispielsweise die DeviceConfigurationOverride.ForcedSize()-Überschreibung angewendet, um die Dichte lokal zu ändern. Dadurch wird das MyScreen-Composable 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: Auf der Haupt-Landingpage für Android-Tests finden Sie einen umfassenderen Überblick über die Grundlagen und Techniken des Testens.
  • Grundlagen des Testens:Hier finden Sie weitere Informationen zu den grundlegenden Konzepten für das Testen einer Android-App.
  • Lokale Tests:Einige Tests können lokal auf Ihrer Workstation ausgeführt werden.
  • 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 Nutzer viele verschiedene Geräte verwenden können, sollten Sie verschiedene Bildschirmgrößen testen.
  • Espresso: Obwohl Espresso für View-basierte UIs gedacht ist, kann es für einige Aspekte von Compose-Tests hilfreich sein.