Erstellungstests werden standardmäßig mit Ihrer UI synchronisiert. Wenn Sie eine
Assertion oder Aktion mit dem ComposeTestRule
, wird der Test synchronisiert
und warten Sie, bis die Struktur der Benutzeroberfläche inaktiv ist.
Normalerweise müssen Sie nichts unternehmen. Es gibt jedoch einige Grenzfälle, die Sie kennen sollten.
Wenn ein Test synchronisiert wird, wird die Schreib-App mithilfe eines virtuelle Uhr. Das bedeutet, dass Compose-Tests nicht in Echtzeit ausgeführt werden und daher bestanden werden können. so schnell wie möglich zu machen.
Wenn Sie die Methoden zum Synchronisieren Ihrer Tests jedoch nicht verwenden, wird neu zusammengesetzt und die Benutzeroberfläche erscheint als pausiert.
@Test
fun counterTest() {
val myCounter = mutableStateOf(0) // State that can cause recompositions.
var lastSeenValue = 0 // Used to track recompositions.
composeTestRule.setContent {
Text(myCounter.value.toString())
lastSeenValue = myCounter.value
}
myCounter.value = 1 // The state changes, but there is no recomposition.
// Fails because nothing triggered a recomposition.
assertTrue(lastSeenValue == 1)
// Passes because the assertion triggers recomposition.
composeTestRule.onNodeWithText("1").assertExists()
}
Diese Anforderung gilt nur für „Compose-Hierarchien“, nicht für die der App.
Automatische Synchronisierung deaktivieren
Wenn du über ComposeTestRule
eine Assertion oder Aktion aufrufst, z. B.
assertExists()
, der Test wird mit der Editor-UI synchronisiert. In einigen Fällen
können Sie diese Synchronisierung stoppen und die Uhr selbst steuern. Für
können Sie zum Beispiel die Zeit festlegen,
um genaue Screenshots einer Animation zu erstellen,
an dem die UI immer noch aktiv ist. So deaktivieren Sie die automatische Synchronisierung:
Legen Sie das Attribut autoAdvance
in mainClock
auf false
fest:
composeTestRule.mainClock.autoAdvance = false
In der Regel setzen Sie die Zeit dann selbst fort. Sie können genau einen Schritt
Frame mit advanceTimeByFrame()
oder eine bestimmte Dauer mit
advanceTimeBy()
:
composeTestRule.mainClock.advanceTimeByFrame()
composeTestRule.mainClock.advanceTimeBy(milliseconds)
Inaktive Ressourcen
Mit Compose lassen sich Tests und die UI synchronisieren, sodass jede Aktion und Assertion im inaktiven Zustand ausgeführt werden, bei Bedarf warten oder die Uhr verschieben. Einige asynchrone Vorgänge, deren Ergebnisse sich auf den UI-Status auswirken, können im während der Test sie nicht erkennt.
Erstellen und registrieren Sie diese inaktiven Ressourcen in Ihrem Test, damit sie genutzt werden bei der Entscheidung, ob die zu testende App ausgelastet oder inaktiv ist, berücksichtigt werden. Das solltest du nicht tun müssen Sie nichts weiter tun, es sei denn, Sie müssen zusätzliche inaktive Ressourcen registrieren, wenn Sie einen Hintergrundjob ausführen, der nicht mit Espresso oder Schreiben.
Diese API ist den inaktiven Ressourcen von Espresso sehr ähnlich, um anzugeben, ob
dass das zu testende Subjekt inaktiv oder beschäftigt ist. Registrieren Sie sich mit der Testregel „Compose“
Die Implementierung von IdlingResource
.
composeTestRule.registerIdlingResource(idlingResource)
composeTestRule.unregisterIdlingResource(idlingResource)
Manuelle Synchronisierung
In einigen Fällen müssen Sie die Compose-UI mit anderen Teilen des oder die App, die Sie testen.
Die Funktion waitForIdle()
wartet, bis Compose inaktiv ist, aber die Funktion
hängt von der autoAdvance
-Property ab:
composeTestRule.mainClock.autoAdvance = true // Default
composeTestRule.waitForIdle() // Advances the clock until Compose is idle.
composeTestRule.mainClock.autoAdvance = false
composeTestRule.waitForIdle() // Only waits for idling resources to become idle.
In beiden Fällen wartet waitForIdle()
auch auf ausstehende Zeichen und Layouts.
Karten/Tickets.
Sie können die Uhr auch verschieben, bis eine bestimmte Bedingung erfüllt ist.
advanceTimeUntil()
composeTestRule.mainClock.advanceTimeUntil(timeoutMs) { condition }
Beachten Sie, dass mit der angegebenen Bedingung der Status geprüft werden sollte, der betroffen sein kann. (funktioniert nur im Schreiben-Zustand).
Auf Bedingungen warten
Alle Bedingungen, die von externen Arbeiten abhängig sind, z. B. das Laden von Daten oder
Messen oder zeichnen (d. h. messen oder zeichnen), sollte ein
allgemeineres Konzept wie waitUntil()
:
composeTestRule.waitUntil(timeoutMs) { condition }
Sie können auch eine der
waitUntil
-Assistenten:
composeTestRule.waitUntilAtLeastOneExists(matcher, timeoutMs)
composeTestRule.waitUntilDoesNotExist(matcher, timeoutMs)
composeTestRule.waitUntilExactlyOneExists(matcher, timeoutMs)
composeTestRule.waitUntilNodeCount(matcher, count, timeoutMs)
Zusätzliche Ressourcen
- Apps unter Android testen: Hier werden die wichtigsten Android-Tests aufgeführt. Landingpage einen umfassenderen Überblick über die Grundlagen und Verfahren der Tests bietet.
- Testgrundlagen:Weitere Informationen Kernkonzepte beim Testen einer Android-App.
- Lokale Tests:Sie können einige Tests ausführen. lokal auf Ihrer eigenen Workstation.
- Instrumentierte Tests:Gut instrumentierte Tests durchführen. Das sind Tests, die direkt auf dem Gerät.
- Continuous Integration: Mit Continuous Integration können Sie Ihre Tests in Ihre Bereitstellung einbinden zu erstellen.
- Verschiedene Bildschirmgrößen testen:Mit Geräten verfügbar sind, sollten Sie auf verschiedenen Bildschirmen testen, Größen.
- Espresso: Nur für Aufrufe auf Basis von Aufrufen Benutzeroberflächen und Espresso-Kenntnisse können bei einigen Aspekten von „Compose“ hilfreich sein Tests durchführen.