🍪 Privacy & Transparency

We and our partners use cookies to Store and/or access information on a device. We and our partners use data for Personalised ads and content, ad and content measurement, audience insights and product development. An example of data being processed may be a unique identifier stored in a cookie. Some of our partners may process your data as a part of their legitimate business interest without asking for consent. To view the purposes they believe they have legitimate interest for, or to object to this data processing use the vendor list link below. The consent submitted will only be used for data processing originating from this website. If you would like to change your settings or withdraw consent at any time, the link to do so is in our privacy policy accessible from our home page..

Vendor List | Privacy Policy
Skip to content

Technik Blog

Programmieren | Arduino | ESP32 | MicroPython | Python | Raspberry PI

Menu
  • Projekte
    • LED’s
    • Servo & Schrittmotoren
    • Sound
    • LCD’s
    • Kommunikation
    • Sicherheit
    • Weekend Project
  • Arduino
    • Tutorials
    • ProMini
      • Anschließen & Programmieren
    • Nano
      • Arduino Nano – Übersicht
    • UNO
      • Übersicht
    • MEGA 2560
      • Übersicht
    • Leonardo
      • Übersicht
    • NodeMCU
      • NodeMCU – “Einer für (fast) Alles!”
    • Lilypad
      • Arduino: Lilypad “Jetzt Geht’s Rund!”
    • WEMOS
      • WEMOS D1 – Arduino UNO kompatibles Board mit ESP8266 Chip
      • WEMOS D1 Mini – Übersicht
      • Wemos D1 mini Shields
    • STM32x
      • STM32F103C8T6 – Übersicht
    • Maker UNO
      • Maker UNO – Überblick und Test
    • ATTiny85
      • Mini Arduino mit ATTiny85 Chip
      • ATtiny85 mit dem Arduino UNO beschreiben
  • Android
  • Über mich
  • DeutschDeutsch
  • EnglishEnglish
Menu

Android GUI Test mit Espresso

Veröffentlicht am 28. Dezember 20172. Mai 2023 von Stefan Draeger

Das Testframework Espresso ist im Jahre 2013 in die Android-Bibliothek geflossen und steht somit dem Entwickler für die automatisierte Testfallerstellung zur Verfügung.

Der Vorteil von Espresso gegenüber anderen Methoden des automatisierten Testens ist das dieser sich wie ein „echter“ Benutzer verhält wie Bsp. das Warten wenn der MainThread gerade „belegt“ ist und somit der Benutzer wirklich auf die GUI warten muss. Dieses musste vorher durch ein Thread.sleep() oder anderer nicht so schöner Möglichkeiten gelöst werden.

  • Abhängigkeiten (Dependencies)
  • Ablage der Testfälle
  • Ein einfacher Test
    • Ausführen des Testfalls
      • Vorbedingungen für das Ausführen von Espresso Testfälle
      • Starten des JUnit Testfalls
  • Fazit

Abhängigkeiten (Dependencies)

Um das Testframework verwenden zu können müssen folgende Abhängigkeiten geladen werden:

androidTestCompile 'com.android.support.test:runner:0.5'
androidTestCompile 'com.android.support.test:rules:0.5'

androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', {
    exclude group: 'com.android.support', module: 'support-annotations'
})

androidTestCompile 'com.android.support:support-annotations:24.2.1'
androidTestCompile 'com.android.support.test.espresso:espresso-intents:2.2.2'

//Wird nur benötigt wenn die WebView getestet werden soll.
androidTestCompile 'com.android.support.test.espresso:espresso-web:2.2.2'

androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.2'
androidTestCompile "org.hamcrest:hamcrest-library:1.3"

Nachdem nun Syncronisiert wurde kann mit der Erstellung des ersten Testfalls begonnen werden.

Ablage der Testfälle

Es gibt in der Android IDE zwei Ordner wo Testfälle abgelegt werden.

Ordnerstruktur für die Ablage der Testfälle.
Ordnerstruktur für die Ablage der Testfälle.

In dem Paket mit der Bezeichnung „(androidTest)“ werden die Testfälle abgelegt, welche für die GUI Test zuständig sind und in dem Paket mit der Bezeichnung „(test)“ werden die Testfälle welche allgemeine Businesskomponenten Testen abgelegt.

Ein einfacher Test

Also erstellen wir als Erstes ein Package „espresso“ um die Testfälle zu ordnen. Unter diesem Package werden nun je nach Benutzeraktion weitere Packages angelegt. Somit erhält man eine saubere Struktur in seinen Testfällen.

In meinem Beispiel teste ich die GUI der Android App „ArduinoConsole“. Als Erstes wird die „MainActivity“ getestet und das Design geprüft. D.h. ob die Schaltflächen und Textfelder die richtigen Bezeichnungen haben.

import android.content.Context;
import android.support.test.InstrumentationRegistry;
import android.test.suitebuilder.annotation.LargeTest;

import org.junit.Rule;
import org.junit.Test;
import org.junit.runner.RunWith;

import android.support.test.rule.ActivityTestRule;
import android.support.test.runner.AndroidJUnit4;

import draegerit.de.arduinoconsole.MainActivity;
import draegerit.de.arduinoconsole.R;

import static android.support.test.espresso.Espresso.onView;
import static android.support.test.espresso.assertion.ViewAssertions.matches;
import static android.support.test.espresso.matcher.ViewMatchers.withId;
import static android.support.test.espresso.matcher.ViewMatchers.withText;

/**
 * Testet die Hautpseite {@link MainActivity} der Android Anwendung "ArduinoConsole" auf default Texte und Design.
 */
@RunWith(AndroidJUnit4.class)
@LargeTest
public class MainActivityDesign {

    /**
     * Die {@link ActivityTestRule} wird instanziiert bevor eine Methode
     *
     * @Before gestartet wird und wird nach der Methode @After wieder entfernt.
     */
    @Rule
    public ActivityTestRule<MainActivity> mainActivityRule = new ActivityTestRule<>(MainActivity.class);

    /**
     * Prüft ob der {@link android.widget.Button} Senden die richtige Beschriftung trägt.
     */
    @Test
    public void testSendBtnDefaultText() {
        onView(withId(R.id.sendBtn)).check(matches(withText(getResourceString(R.string.sendBtnTxt))));
    }

    /**
     * Liefert einen String aus der Resourcedatei.
     *
     * @param id - ID der String Resource
     * @return String
     */
    private String getResourceString(int id) {
        Context targetContext = InstrumentationRegistry.getTargetContext();
        return targetContext.getResources().getString(id);
    }

}

Analysieren wir die Zeile 40 etwas genauer:

 onView(withId(R.id.sendBtn)).check(matches(withText(getResourceString(R.string.sendBtnTxt))));
  1. onView – sucht auf der Activity welche mit der Annotation @Rule gewählt wurde,
  2. withId – die Komponente mit der ID
  3. check – prüft
  4. matches – ob es zutrifft

In diesem Fall suche ich auf der MainActivity die Komponente mit der ID R.id.sendBtn und prüfe ob der Button den Text aus der Resource R.string.sendBtnTxt enthält.

Gemäß den Android Developern sollte auf der Activity mit der Methode „withText“ gesucht werden denn die ID ist nicht unbedingt unique und somit kann es zu Fehlern kommen.

Eine ausführliche Referenz der Matcher findet man auf der Seite https://developer.android.com/reference/android/support/test/espresso/matcher/ViewMatchers.html.

Ausführen des Testfalls

Der bzw. die Testfälle lassen sich auf „echten“ Geräten bzw. auch auf Emulatoren ausführen. In diesem Kapitel möchte ich erläutern, wie die Testfälle auf „echten“ Geräten ausgeführt werden.

Vorbedingungen für das Ausführen von Espresso Testfälle

In den Entwickleroptionen des Gerätes müssen folgende Einstellungen getroffen werden:

  • Window-Animationsgröße – Wert -> „Animationsgröße 1x“
  • Übergangs-Animationsgröße – Wert -> „Animationsgröße 1x“
  • Animator-Dauerskala – Wert -> „Animationsgröße 1x“
EntwicklerOptionen Android Espresso Einstellungen
EntwicklerOptionen Android Espresso Einstellungen

Starten des JUnit Testfalls

Nachdem die Einstellungen getroffen wurden kann nun der Testfall über das Kontextmenü gestartet werden.

Bei der Ausführung von den Testfällen muss das Gerät „wach bleiben“ d.h. der Bildschirm muss aktiv bleiben, ansonsten wird der Testfall auf einen Fehler laufen und dieses mit folgender Fehlermeldung quittieren:

Exception - Display nicht aktiv.
Exception – Display nicht aktiv.

Wenn nun der Testfall ausgeführt wird, wird je nach Aktion die App „flackern“, das ist normal, denn die Ausführung ist sehr schnell.

Fazit

Die Erstellung von Testfällen für eine Android-App ist mit dem Framework Espresso sehr einfach und sehr schnell. Für alle aktuellen Android Projekte verwende ich dieses Framework, denn damit kann man verschiedene Test auf mehreren Geräten schnell ablaufen lassen, somit spart man deutlich an Zeit.

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Kategorien

Tools

  • 8×8 LED Matrix Tool
  • 8×16 LED Matrix Modul von Keyestudio
  • 16×16 LED Matrix – Generator
  • Widerstandsrechner
  • Rechner für Strom & Widerstände
  • ASCII Tabelle

Meta

  • Videothek
  • Impressum
  • Datenschutzerklärung
  • Disclaimer
  • Kontakt
  • Cookie-Richtlinie (EU)

Links

Blogverzeichnis Bloggerei.de Blogverzeichnis TopBlogs.de das Original - Blogverzeichnis | Blog Top Liste Blogverzeichnis trusted-blogs.com
©2023 Technik Blog | Built using WordPress and Responsive Blogily theme by Superb
x
x