Loading content
Espresso ist ein Android UI-Testframework von Google zur automatisierten Interaktion und Prüfung von Benutzeroberflächen. Es ermöglicht synchrone, wiederholbare Tests mit klaren APIs für Aktionen und Assertions. Besonders geeignet für instrumentierte Tests auf Gerät oder Emulator und CI-Pipelines.
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und verwandte Bausteine zu öffnen.
Technischer Baustein: kann automatisiert, integriert oder betrieben werden.
Konkretes Rädchen im System, das in größeren Zusammenhängen wirkt.
Espresso ist Googles Android-Framework für instrumentierte UI-Tests. Es steuert App-Oberflächen automatisiert und prüft sichtbares Verhalten mit präzisen Aktionen und Assertions.
Espresso wurde bei Google für instrumentierte Android-UI-Tests entwickelt, damit Teams App-Oberflächen reproduzierbar bedienen und prüfen können. Der konkrete Auslöser war der Bedarf an synchronen Tests auf Gerät oder Emulator ohne fragile Sleeps oder manuelle Eingriffe. Daraus entstand ein kompaktes API-Modell für Aktionen und Assertions im Android-Test-Stack.
Stell dir Espresso als Prüfstand direkt vor der laufenden App vor. Der Test sucht ein UI-Element, führt eine Aktion aus, liest den sichtbaren Zustand und vergleicht ihn mit einer Assertion. Das Framework koordiniert die Ausführung so, dass Interaktionen in einem stabilen Zustand bewertet werden. Dadurch eignen sich die Tests besonders für wiederholbare Abläufe und Regressionen.
Die Tests laufen gegen eine installierte App auf Gerät oder Emulator statt nur gegen isolierte Logik.
Testcode identifiziert die relevanten Oberflächenelemente eindeutig, bevor er mit ihnen interagiert.
Klicks, Eingaben und andere Benutzerhandlungen werden kontrolliert auf dem UI ausgeführt.
Nach einer Interaktion wird geprüft, ob Text, Sichtbarkeit oder anderer Zustand dem Erwarteten entspricht.
Das Framework wartet auf einen belastbaren UI-Zustand, damit Prüfungen nicht an Timing-Problemen scheitern.
Espresso ist hilfreich, wenn Android-Teams stabile Tests für kritische Bedienpfade, Regressionen und Release-Gates brauchen. Es ist besonders stark auf Gerät oder Emulator und in CI-Pipelines, ersetzt aber kein Unit-Testing. Asynchrone Abläufe, externe Dienste und schlecht synchronisierte UI-Logik können Wartung und Fehlalarme erhöhen.
Wo dieser Baustein im Themenmodell verortet ist.
Keine Strukturpfade verfügbar.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.