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)
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.
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))));
- onView – sucht auf der Activity welche mit der Annotation @Rule gewählt wurde,
- withId – die Komponente mit der ID
- check – prüft
- 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”
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:
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.