ANDROID TESTING. Testautomation und Continuous Integration für Android. Wunderschöne UIs. Android-Fragmentierung. Unterwegs programmieren

Transkript

1 Ausgabe 4/2011 Brandneu: Die neuen Features von Android Ice Cream Sandwich! Deutschland 9,80 Österreich 11,70 Schweiz sfr 17,50 Luxemburg 11,90 magazin ANDROID TESTING Testautomation und Continuous Integration für Android Strategien Werkzeuge Tipps Wunderschöne UIs Android und Drawable Ressourcen Android-Fragmentierung Die Vielfalt der Plattform als Chance Unterwegs programmieren Tools für das Coding in Bus und Bahn Warum scheitern mobile Projekte? Die Knackpunkte unter der Lupe

2 testen mit android TiTelThema Teststrategien und -werkzeuge für mobile Anwendungen in Android Tut er s oder tut er s nicht? Das Testen stellt im mobilen Umfeld eine ungleich größere Herausforderung dar als in anderen Bereichen der Softwareentwicklung. Sie entsteht durch die hohe Vielfalt der Geräte und die damit einhergehenden Variationen der Hard- und Softwarekonfi gurationen und -versionen. von arne Limburg Bei der Entwicklung einer Teststrategie für mobile Anwendungen muss auf diese Vielfalt der Geräte eingegangen werden, die gleichzeitig eine Vielfalt von Bildschirmauflösungen, Eingabemethoden (Touchscreen, Multi-Touch, Trackball, externe Tastatur usw.) und Konfigurationsmöglichkeiten mit sich bringt. Benötigt zum Beispiel eine Anwendung Positionsdaten, muss nicht nur überprüft werden, ob das Gerät überhaupt in der Lage ist, diese zu liefern, sondern auch, ob die gelieferten Positionsdaten für den entsprechenden Anwendungsfall präzise genug sind. Die Genauigkeit von Positionsdaten kann erheblich variieren, je nachdem ob sie von einem GPS-Empfänger kommen, aus der Information über die Mobilfunkzelle, in die das Gerät gerade eingeloggt ist, oder aus dem aktuellen IP-Bereich (z. B. über WLAN). Ähnliche Komplexitäten ergeben sich unter anderem bei der Verwendung von Kamera, Kompass- und/oder Lagesensor. Ein weiterer Punkt, der vor allem bei mobilen Anwendungen ins Gewicht fällt, ist die Vielfalt der Umwelteinflüsse. So müssen der aktuelle Standort (im Wald oder in Häuserschluchten funktioniert GPS schlechter als auf dem freien Feld), der Batteriestand, die Netzqualität und viele weitere Faktoren berücksichtigt werden. Auch das Nutzerverhalten stellt bei der mobilen Anwendung eine besondere Herausforderung dar. So kann es passieren, dass der Benutzer während einer Texteingabe auf die Idee kommt, das Handy vom Hoch- ins Querformat zu drehen und damit eine komplette Neuberechnung des Layouts anzustoßen. Weitere Herausforderungen stellen plötzlich eingehende Anrufe dar oder zum Beispiel die Betätigung des Lautstärkereglers oder des Zurück-Knopfes. Wahl der richtigen Teststrategie Die oben aufgeführten Probleme der mobilen Anwendungsentwicklung stellen auch eine besondere Herausforderung an das Testen solcher Anwendungen dar. Es wird niemals möglich sein, alle Kombinationen von Hard- und Software, Umwelteinflüssen und Benutzerverhalten zu testen. Das führt dazu, dass beim Testen Kompromisse eingegangen werden müssen. Es gibt mehrere Testmethoden, mit denen die verschiedenen Bereiche der oben genannten Felder getestet werden können. Diese Testmethoden haben dabei unterschiedliche Vorund Nachteile. Die Erstellung einer Teststrategie besteht darin, die Vor- und Nachteile der einzelnen Methoden gegeneinander abzuwägen und zu gewichten und somit jeder Testmethode den richtigen Platz und Umfang im Entwicklungs- und Testprozess zu geben. Diese Aus- Testkontexte android bietet drei Varianten, um in einem test das Context-objekt zu ersetzen: mockcontext: Keine methode ist implementiert, d. h. alle methoden werfen exceptions. er eignet sich, um von ihm abzuleiten, wenn man einen eigenen testcontext schreiben muss und nur einzelne methoden implementieren möchte. isolatedcontext: damit läuft ein test isoliert vom Gesamtsystem ab. datei- und datenbankoperationen erfolgen in einem separaten testbereich, wodurch dieser Context sehr gut geeignet ist, um diese zu testen. die meisten systemaufrufe liefern stub-antworten. einige aufrufe werfen exceptions. renamingdelegatingcontext: es delegiert alle systemaufrufe an einen echten Context. datei- und datenbankaufrufe erfolgen wie beim isolatedcontext in einem separaten Bereich android

3 Titelthema testen mit android Listing 1 wahl und Gewichtung ist ein wiederkehrender Prozess, in dem auf Basis der individuellen Anforderungen die jeweils richtige Teststrategie entwickelt wird. public class MyProviderTest extends ProviderTestCase2<MyProvider> { public static final String NAME = "test"; public MyProviderTest() { super(myprovider.class, MyProviderMetaData.AUTHORITY); public void testinsert() { //test ContentValues contentvalues = new ContentValues(); contentvalues.put(myprovidermetadata.name, NAME); MockContentResolver contentresolver = getmockcontentresolver(); Uri uri = contentresolver.insert(myprovider.content_uri, contentvalues); //verify String[] projection = new String[] {MyProviderMetaData.NAME; Cursor cursor = getprovider().query(uri, projection, null, null, null); cursor.movetofirst(); assertequals(name, cursor.getstring(0)); asserttrue(cursor.islast()); Listing 2 public class MyNetworkServiceTest extends ServiceTestCase<MyNetworkService> { public MyNetworkServiceTest() { super(mynetworkservice.class); public void testpostrequest() { MyNetworkService.MyNetworkServiceBinder servicebinder = (MyNetworkServiceBinder)bindService(new Intent(getContext(), MyNetworkService.class)); MockHttpClient mockhttpclient = new MockHttpClient(); getservice().sethttpclient(mockhttpclient); servicebinder.postrequest(); asserttrue(mockhttpclient.getrequest() instanceof HttpPost); Priorisierung und Automatisierung Um in den Tests die Vielfalt der Geräte und Konfigurationen annähernd abdecken zu können, gibt es ein paar Punkte, die unbedingt berücksichtigt werden sollten. Es ist nicht möglich, auf allen späteren Endgeräten zu testen. Das ist allein schon durch die Tatsache bedingt, dass bei der Schnelllebigkeit im Handymarkt viele der potenziellen Endgeräte zum Zeitpunkt der Anwendungsentwicklung noch gar nicht auf dem Markt sind. Aus dieser Tatsache sollten zwei Konsequenzen gezogen werden: 1. Man sollte so viele Tests wie möglich mit verschieden konfigurierten AVDs (Android Virtual Devices) ausführen. Das ist dank des mitgelieferten Android- Emulators recht einfach. 2. Man sollte beim Testen auf echten Geräten den Fokus auf eine Auswahl wichtiger Zielgeräte und auf Tests legen, die mit dem Emulator nicht oder nicht in ausreichendem Maße durchgeführt werden können, z. B. die Kommunikation über GPRS mit verschiedenen Telekommunikationsanbietern. Diese Anforderungen lassen sich nur durch ein hohes Maß an Testautomatisierung erfüllen. Das automatische Testen ist daher ein Kernbestandteil mobiler Teststrategien. Unit Tests Die am einfachsten zu automatisierende Testmethode ist das Unit Testing. Hierbei handelt es sich um das Testen kleinstmöglicher Einheiten, also in der Regel das Testen der korrekten Funktion einzelner Klassen und Methoden. Der große Vorteil von Unit Tests ist, dass sie aufgrund ihres geringen Umfangs eine kurze Ausführungsdauer haben und dadurch häufig ausgeführt werden können. Die größte Herausforderung beim Unit Testing ist die Entkopplung der zu testenden Klasse vom Gesamtsystem. Diese Herausforderung wird im mobilen Umfeld umso größer, da hier in der Regel die Abhängigkeit zu der Laufzeitumgebung viel höher ist als in anderen Bereichen der Softwareentwicklung. Um diese Entkopplung zu erreichen, werden alle Abhängigkeiten mit Mock-Objekten (engl. für Attrappe) gefüllt. Das Android-Testframework bringt bereits Mock-Objekte für die üblichen Abhängigkeiten von Android-Anwendungen wie MockApplication, MockContext, MockContentPro vider mit (Kasten: Testkontexte ). Neben den Mock-Objekten liefert Android eine komplette Integration in JUnit, allerdings nur für Version 3. Hier gibt es Oberklassen zum Testen der Android-Komponenten wie ApplicationTestCase, LoaderTestCase, ProviderTestCase2, ServiceTestCase, ActivityUnitTestCase und ActivityInstrumentationTest Case2. Die damit erstellten Testklassen werden zusammen mit der zu testenden Anwendung auf dem Gerät oder dem Emulator installiert und können dann über die Android Debug Bridge (ADB) direkt auf dem Gerät oder Emulator ausgeführt werden. Über adb-parameter kann auch gesteuert werden, welche Tests ausgeführt werden sollen. So ist neben der Ausführung aller Tests des Projekts auch die Beschränkung auf einzelne Tests oder Testgruppen möglich. Testgruppen können gebildet werden, indem die Tests mit einer annotiert werden. Auch die Definition eigener Annotations ist möglich. Um eine Trennung von Anwendung und Tests 46 android

4 testen mit android Titelthema zu erreichen, werden die Tests in ein separates Testprojekt ausgelagert. In Eclipse kann es direkt über New Android Test Project angelegt werden. Im darauf folgenden Wizard wird dann das zu testende Projekt angegeben. Wie bereits erwähnt, gibt es für die verschiedenen Android-Komponenten jeweils eine Testoberklasse, von denen die drei wichtigsten hier vorgestellt werden. Testen eines ContentProviders Zum Testen eines ContentProviders bietet das Android- Testframework die Klasse ProviderTestCase2. An der nachgestellten 2 lässt sich erkennen, dass es sich bereits um die zweite Version dieser Klasse handelt. Android hat das Testframework überarbeitet und einige Testoberklassen ersetzt. Die Klasse ProviderTestCase2 nimmt bei der Testerstellung einige Arbeit ab. So instanziiert sie automatisch den zu testenden ContentProvider und versieht ihn dabei mit einem IsolatedContext (Kasten: Testkontexte ). Dadurch kann es nicht passieren, dass der Unit Test aus Versehen den Rest des Testsystems beeinflusst. Datei- und vor allem Datenbankoperationen sind mit dem IsolatedContext aber möglich, was wichtig ist, weil das die Operationen sind, die bei einem ContentProvider in der Regel (je nach Implementierung) getestet werden müssen. Zugreifen kann man auf den ContentProvider über einen MockContentResolver, der auch von der Testklasse zur Verfügung gestellt wird und über getmockcontentresolver() verwendet werden kann. Die Verwendung dieses MockContentResolvers ist dem direkten Zugriff auf den ContentProvider vorzuziehen, da später der Zugriff der realen Anwendung auf den ContentProvider auch immer über einen ContentResolver erfolgen wird. Zu testen sind natürlich alle zur Verfügung stehenden Operationen des ContentProviders. Sie werden über die Menge der URIs definiert, die der ContentProvider akzeptiert. Das Verhalten des ContentProviders bei ungültigen URIs sollte auch getestet werden. Listing 1 zeigt exemplarisch das Testen der Insert-Operation eines ContentProviders. Testen eines Service Android-Services haben einen klar definierten Lebenszyklus [2]. Die Oberklasse ServiceTestCase sorgt dafür, dass er während des Tests automatisch durchlaufen wird. Dazu bietet die Oberklasse über die Methoden startservice( ) und bindservice( ) genau die Schnittstelle, mit der später im echten Anwendungscode auch der Service gestartet wird. Das Testen der Businesslogik eines Service ist häufig recht schwierig, weil Services in der Regel asynchron ablaufen. Über den von der Methode bindservice( ) zurückgegebenen ServiceBinder können zwar im Test Servicemethoden aufgerufen werden, wenn die aufgerufene Methode aber einen eigenen Thread startet (was bei lang laufenden Operationen zu empfehlen ist), ist es nicht leicht, im Test festzustellen, dass die Ausführung der Servicemethode beendet ist, sodass sich dann auch schwer feststellen lässt, ob sie das getan hat, was man erwartet hat. Listing 2 zeigt den Test eines NetworkServices, der beim Aufruf der Methode postrequest( ) einen Thread startet und asynchron einen HTTP Request absetzt. Beim Testen dieses asynchronen Aufrufs unterstützt uns die Klasse CountDownLatch aus dem java.util.concurrent Package. Über deren Methode countdown() kann der aufgerufene Thread einen Zähler herunterzählen und der Aufrufer kann über die Methode await() warten, bis der Zähler auf 0 ist. Um in unserem Beispiel testen zu können, ob der Aufruf von postrequest( ) tatsächlich zu einem HTTP Request führt, können wir den Http Client, der von dem NetworkService verwendet wird, durch ein Mock-Objekt (Listing 3) ersetzen. Dieser MockHttpClient verwendet den eben genannten Count DownLatch, der beim erwarteten Aufruf der Methode execute( ) heruntergezählt wird. Der Testcode kann nun über getrequest() auf den übergebenen Request zugreifen und überprüfen, ob der NetworkService tatsächlich einen korrekten Request abgesetzt hat. Erfolgt der Aufruf der Methode getrequest() vor dem Aufruf der Methode execute( ), so wartet der MockHttpClient zunächst durch den Aufruf von CountDownLatch. await( ), bis der Aufruf von execute( ) erfolgt ist und den Zähler vermindert hat. Um sicherzugehen, dass der Test nicht ewig wartet (weil der Service nie HttpClient. execute( ) aufruft), wird die Methode await( ) mit einem Timeout versehen. Testen einer Activity Das Testen einer Activity losgelöst vom Gesamtsystem (also als Unit Test) gestaltet sich besonders schwierig, weil Activities automatisch eine Vielzahl von Verbin- Listing 3 public class MockHttpClient implements HttpClient { private HttpUriRequest request; private CountDownLatch latch = new CountDownLatch(1); public HttpUriRequest getrequest() { try { latch.await(10, TimeUnit.SECONDS); catch (InterruptedException e1) { //nothing to do here return request; public HttpResponse execute(httpurirequest request) { this.request = request; latch.countdown(); BasicStatusLine line = new BasicStatusLine(HttpVersion.HTTP_1_1, 200, "OK"); return new BasicHttpResponse(line); //other mock methods omitted android

5 Titelthema testen mit android Listing 4 dungen mit der Anwendungsinfrastruktur haben. Die Oberklasse ActivityUnitTestCase kapselt die zu testende Activity dennoch recht gut vom Gesamtsystem ab. Das hat aber zur Folge, dass einige Methodenaufrufe der Activity zu Exceptions führen und daher nicht in einem Unit Test getestet werden können. Hierbei handelt es sich vor allem um Methoden zur Interaktion zwischen verschiedenen Activities wie startactivity FromChild( ) oder creatependingresult( ). Einige Dinge lassen sich dennoch isoliert testen, zum Beispiel der einfache Aufruf einer Folge-Activity. Der Trick ist public class MyListActivityUnitTest extends ActivityUnitTestCase<MyListActivity> { private static final long ENTRY_ID = 42; public MyListActivityUnitTest() { super(mylistactivity.class); public void testonlistitemclick() { //test Intent listintent = new Intent(getInstrumentation().getTargetContext(), MyListActivity.class); startactivity(listintent, null, null); getactivity().onlistitemclick(null, null, 0, ENTRY_ID); //verify Intent startedintent = getstartedactivityintent(); assertnotnull(startedintent); assertequals(mydetailactivity.class.getname(), startedintent.getcomponent().getclassname()); long entryid = (Long)startedIntent.getSerializableExtra("ENTRY_ID"); assertequals(entry_id, entryid); Testen von Seiteneffekten wie Telefonanruf oder niedriger Batteriestand Detaillierten Zugriff auf den Emulator bietet die DDMS-Perspektive von Eclipse. Hier hat man die Möglichkeit, den Eingang eines Telefonanrufs oder einer SMS am Emulator zu simulieren. Des Weiteren lässt sich die Netzgeschwindigkeit steuern und die GPS-Koordinaten des Emulators setzen. Wem die Möglichkeiten der Perspektive nicht ausreichen, der kann sich über telnet localhost <Port> mit dem Emulator verbinden (den Port des Emulators findet man in der Titelzeile des Emulatorfensters). Hier stehen weitere Möglichkeiten der Steuerung des Emulators zur Verfügung, zum Beispiel das Setzen des Batteriestandes. Die Eingabe von help listet alle Befehle auf. Theoretisch könnten über die Telnet- Schnittstelle des Emulators diese Seiteneffekte zwar auch automatisiert getestet werden, in der Praxis ist das aber recht kompliziert. Es empfiehlt sich daher, diese Seiteneffekte manuell auszulösen, während gerade ein automatisierter Funktionstest läuft, um so die Reaktion der Anwendung auf die Seiteneffekte zu testen. hier, dass die Folge-Activity nicht tatsächlich gestartet wird (dann wäre es kein Unit Test mehr), man aber später überprüfen kann, ob der Aufruf zum Start (nämlich startactivity( ) oder startactivityforresult( )) tatsächlich erfolgt ist. Das ist über die Methoden getstartedactivityintent() und getstartedactivityrequest() möglich, die von der Oberklasse ActivityUnitTest zur Verfügung gestellt werden. Listing 4 zeigt den Unit Test einer ListActivity, die beim Klick auf einen Listeneintrag in eine Detailansicht springt und dabei eine ID in dem Intent übergeben soll. Nach dem Aufruf der Methode der Activity wird dann über getstartedactivity Intent() überprüft, ob die korrekten Werte im Intent tatsächlich enthalten sind. Funktionale Tests Neben den reinen Unit Tests ist es mit dem Android- Testframework auch möglich, komplette Funktionstests zu erzeugen, die das gesamte UI-Verhalten (vom Klick bis zum Ergebnis der ausgelösten Aktion) oder sogar ganze Klickpfade und damit ganze Use Cases testen. Betrachtet man das obige Beispiel von der ListActivity, wäre es beispielsweise wünschenswert, dass nicht nur die korrekte Funktion der Activity getestet werden könnte, sondern der gesamte Flow vom tatsächlichen Klick auf das UI-Element (in diesem Fall eine Liste) bis zum Start der Detailansicht. Das ist tatsächlich möglich, wenn man als Oberklasse den ActivityInstrumentationTestCase2 verwendet. Die Kommunikation mit der Android-Infrastruktur ermöglicht dabei die Klasse Instrumentation, die innerhalb des Tests über getinstrumentation() zur Verfügung steht. Mit ihr ist es möglich, direkt mit dem Emulator oder dem Device in Interaktion zu treten und zum Beispiel Activities zu starten oder Tastatureingaben zu simulieren. Wer Texteingaben (oder andere Attribute) lieber auf dem View direkt setzen will, indem er ihn über findviewbyid( ) holt und den entsprechenden Wert dann über set setzt, muss das im UI Thread von Android tun. Hierzu gibt es zwei Möglichkeiten: Entweder man verwendet die Methode runonuithread( ) der Activity oder man versieht den gesamten Test mit der Listing 5 zeigt einen Test, der die aus dem Test aus Listing 3 bekannte Listenansicht testet und hierzu die Instrumentation verwendet. Damit wird nicht nur die korrekte Funktion der Activity getestet, sondern tatsächlich über die Simulation eines Fingerdrucks auf die Liste, der über die Klasse TouchUtils erzeugt werden kann, der gesamte Programmfluss bis zum Start der DetailActivity. Über die Instrumentation ist es möglich, einen Monitor für die DetailActivity zu erzeugen und damit auf deren Aufruf zu warten. Eine andere Möglichkeit wäre es, ein sleep( ) in den Test einzubauen. Das beinhaltet aber das Risiko, dass die Anwendung zu langsam reagiert und der Test deshalb fehlschlägt. Um dieses Risiko zu minimieren, gibt es die Hiermit kann für einen Test angegeben werden, dass der Test bei einem einmaligen Fehlschlag wiederholt werden soll, 48 android

6 testen mit android Titelthema und erst wenn der Test mehrmals nicht erfolgreich ausgeführt werden kann, gilt er als fehlgeschlagen. Wie oft er wiederholt werden soll, kann dabei durch die Angabe eines Wertes für das tolerance-attribut in der Annotation festgelegt werden. In Listing 5 enthält die Detail Activity einen TextView. Hier wird zum Schluss über die Klasse ViewAsserts getestet, ob dieser sichtbar ist. Danach wird anhand des Inhalts überprüft, ob die DetailActivity mit den korrekten Daten aufgerufen wurde. Eine weitere Vereinfachung von funktionalen Tests bietet die Zusatzbibliothek Robotium [3] (siehe auch Artikel auf Seite 58). Mit ihr ist es möglich, funktionale Tests als Blackboxtests durchzuführen, das heißt dass es nicht nötig ist zu wissen, aus welchen Views eine Activity aufgebaut ist. Mit der Klasse Solo kann direkt der Klick auf eine Koordinate auf dem Bildschirm simuliert werden oder sogar der Klick auf einen bestimmten Text, der auf dem aktuellen Bildschirm zu sehen ist. Listing 6 zeigt ein Beispiel für einen Robotium-Test der bereits bekannten ListActivity. Continuous Integration Betrachtet man den Funktionstest unserer ListActivity, stellt sich die Frage, wozu überhaupt Unit Tests benötigt werden, wenn sich doch die ganze Anwendung über komplette Funktionstests testen lässt. Eine erste schnelle Antwort kommt sofort in den Sinn, wenn man die Activity Unit Test vs. Activity-Funktionstest In einem Unit Test wird nur die Funktionalität der Activity selbst getestet, das heißt es wird getestet, was passiert, wenn die entsprechende Methode (in Listing 4 die Methode onlistitemclick( )) aufgerufen wird. Auch wird die nachfolgende Activity nicht tatsächlich gestartet, sondern der Aufruf von startactivity( ) wird nur aufgenommen und es kann später über getstartedactivityintent() überprüft werden, ob er tatsächlich stattgefunden hat. Durch Auslesen der Extra-Informationen aus dem Intent wird überprüft, ob die Activity den Intent auch mit den richtigen Parametern erzeugt hat. Im Gegensatz dazu wird bei dem Funktionstest tatsächlich der Klick auf das UI-Element simuliert. Dann wird überprüft, ob tatsächlich die DetailActivity gestartet wird. Ob die Activity mit den richtigen Parametern gestartet wurde, wird hier getestet, indem die UI- Elemente der DetailActivity untersucht werden. beiden Tests im Vergleich betrachtet: Der Funktionstest ist deutlich komplexer als der Unit Test und ein Unit Test daher offensichtlich deutlich leichter zu schreiben. Eine weitergehende Antwort ist im Entwicklungsprozess begründet. Das Ziel von Unit Tests ist es zum einen, durch Testen kleiner Einheiten einen möglichen Fehler schnell eingrenzen zu können, und zum anderen durch häufige Testausführung einen Fehler im Laufe des Entwicklungsprozesses früh zu erkennen. Diese frühe Erkennung von Fehlern gewährleistet der Einsatz eines Anzeige

7 Titelthema testen mit android Listing 5 public class MyListActivityUiTest extends ActivityInstrumentationTestCase2<MyListActivity> { private MyListActivity activity; private ListView view; public MyListActivityUiTest() { super("de.mypackage", MyListActivity.class); public void setup() { Intent intent = new Intent(Intent.ACTION_MAIN); intent.setflags(intent.flag_activity_new_task); intent.setclassname(getinstrumentation().gettargetcontext(), MainActivity.class.getName()); getinstrumentation().startactivitysync(intent); activity = getactivity(); view = (ListView)activity.findViewById(android.R.id.list); public void testclickonlist() { //test String classname = MyDetailActivity.class.getName(); ActivityMonitor monitor = getinstrumentation().addmonitor(classname, null, false); TouchUtils.clickView(this, view.getchildat(0)); MyDetailActivity detailactivity = (MyDetailActivity)monitor.waitForActivity(); //verify assertnotnull(detailactivity); TextView idview = (TextView) detailactivity.findviewbyid(r.id.txt_id); ViewAsserts.assertOnScreen(detailActivity.getWindow().getDecorView(), idview); assertequals("42", idview.gettext().tostring()); Listing 6 public class MyListActivityRobotiumTest extends ActivityInstrumentationTestCase2<MyListActivity> { public MyListActivityRobotiumTest() { super("de.mypackage", MyListActivity.class); public void testclick() { Solo solo = new Solo(getInstrumentation(), getactivity()); solo.assertcurrentactivity("expected MyListActivity", MyListActivity.class); solo.clickonscreen(100, 200); solo.assertcurrentactivity("expected MyDetailActivity", MyDetailActivity.class); asserttrue(solo.searchtext("42")); Continuous-Integration-Servers. Für die Server Hudson beziehungsweise Jenkins gibt es ein Android-Plug-in, das dafür sorgt, dass vor der Ausführung der Tests ein Android-Emulator gestartet wird, der nach dem Beenden der Tests automatisch wieder gestoppt wird. Soll ein anderer Continuous-Integration-Server verwendet werden, muss das Starten und Stoppen des Emulators in das Build Script integriert werden. Durch die Verwendung von Continuous Integration ist es möglich, alle Unit Tests regelmäßig sofort nach dem Einchecken der Codeänderung auszuführen und den Entwickler dadurch umgehend automatisiert per zu informieren, wenn seine Codeänderung einen Programmfehler beinhaltet oder einen unerwünschten Seiteneffekt auf andere Codeteile hat. Es empfiehlt sich dabei, den Continuous-Integration-Server so zu konfigurieren, dass alle Unit Tests unmittelbar nach Codeänderungen (also nach dem Commit eines Entwicklers) durchgeführt werden. Die Funktionstests, deren Ausführung deutlich länger dauert, sollten hingegen maximal einmal täglich ausgeführt werden. Auf diese Art und Weise kann bereits während des Entwicklungsprozesses sichergestellt werden, dass die bereits umgesetzten Teile der Anwendung fehlerfrei funktionieren. Dadurch wird gewährleistet, dass nach Umsetzung aller Features bereits eine qualitativ hochwertige Software an die Testabteilung übergeben werden kann. Abnahme- und Regressionstests Alle bisher vorgestellten Testmethoden basieren auf JUnit und damit auf dem Schreiben von Testcode in Java. Diese Tatsache führt dazu, dass die obigen Tests in der Regel nicht dazu geeignet sind, von Testabteilungen erstellt zu werden, weil deren Java-Kenntnisse meistens begrenzt oder gar nicht vorhanden sind. Um den Anforderungen des Testens durch Testabteilungen gerecht zu werden, liefert Android ein Tool, das die Definition der Tests über eine Skriptsprache (in diesem Fall das Python-Derivat Jython) ermöglicht. Das Tool heißt Monkeyrunner. Mit ihm kann man Android- Emulatoren oder Devices ohne die Verwendung von Java-Code steuern. Möglich wird das durch die Klassen MonkeyRunner, MonkeyDevice und MonkeyImage. Mit der Klasse MonkeyRunner ist es über die Methode waitforconnection möglich, sich mit einem Device oder Emulator zu verbinden. Als Parameter kann neben einem Timeout die Seriennummer des Geräts angegeben werden, wie sie von der Android Debug Bridge (ADB) vergeben wird. Wenn nur ein Gerät an den Computer angeschlossen beziehungsweise eine Emulator-Instanz gestartet ist, kann die Seriennummer auch weggelassen werden. Ansonsten lassen sich die Seriennummern der angeschlossenen Geräte und gestarteten Emulatoren über den Kommandozeilenbefehl adb devices ausgeben. Die Methode waitforconnection liefert bei erfolgreicher Verbindung zu einem Gerät oder Emulator ein Objekt vom Typ MonkeyDevice zurück. Mit ihm ist es möglich, zunächst die zu testende Anwendung zu instal- 50 android

8 testen mit android Titelthema lieren, zu starten und dann skriptgesteuert Tests durchzuführen. Ein Beispiel-Script kann unter [4] eingesehen werden. Um das Ergebnis mit dem erwarteten Ergebnis vergleichen zu können, bietet die Klasse MonkeyDevice über die Methode takesnapshot die Möglichkeit, ein Bildschirmfoto zu erstellen. Der Rückgabewert ist vom Typ MonkeyImage, das dann mit früher erstellten Bildschirmfotos über die Methode sameas( ) verglichen werden kann. Leider ist es momentan noch nicht möglich, auch Bilder von der Festplatte zu laden. Das soll aber in einem späteren Release des MonkeyRunners hinzugefügt werden. Da es sich bei dem Bildschirmfoto tatsächlich um ein Foto des kompletten Bildschirms handelt, muss man bei dem Vergleich berücksichtigen, dass auch Uhrzeit und Batteriestatus enthalten sind. Ein 1:1-Vergleich mit einem vorher erstellten Screenshot wird also in der Regel fehlschlagen. Um das zu umgehen, gibt es zwei Möglichkeiten. Entweder man gibt beim Bildvergleich über sameas( ) als zweiten Parameter einen Prozentwert an, zu dem sich die Bilder ähneln müssen, oder man wählt über die Methode getsubimage( ) den Bildbereich aus, den man tatsächlich vergleichen möchte. Über diesen Bildvergleich kann überprüft werden, ob der Test bestanden wurde oder nicht. Legt man nun für jede zu testende Android-Version und für verschiedene Hardwarekonfigurationen ein AVD (Android Virtual Device) an und startet für jedes AVD eine Emulator-Instanz, lassen sich die so erstellten Abnahmetests hervorragend (auch automatisiert) parallel auf den verschiedenen Emulator-Instanzen ausführen und es kann ein breites Spektrum an Hard- und Softwarekonfigurationen und -version parallel getestet werden, indem man jeweils dem Jython Script die Seriennummer der zu testenden Emulator-Instanz als Parameter übergibt. Auf die gleiche Weise können die Tests auch auf echten Geräten durchgeführt werden. Außerdem lassen sich diese Abnahmetests für spätere Versionen der Software auch hervorragend als Regressionstests verwenden. Stresstests Ziel eines Stresstests ist es, dass sich die Anwendung stabil verhält, egal was die Endbenutzer mit ihren Geräten anstellen. Man würde sein Handy sicher keinem Affen in die Finger geben, aber in Anspielung auf dessen mögliches Vorgehen in einer solchen Situation liefert Android neben dem MonkeyRunner ein weiteres Affentool : das Tool Monkey [5]. Mit diesem ist es möglich, zufälliges Benutzerverhalten zu simulieren, also eine (pseudo-)zufällige Folge von Touch-Events, Gesten, Tastatureingaben, Handytastendruck (Zurück-Taste, Home-Taste, Lautstärkeregelung etc.) und weitere Ereignisse wie die Bildschirmrotation usw. anzustoßen. Dabei sind die Anzahl der Events und der Abstand zwischen den einzelnen Events konfigurierbar. Mit dem Monkey lassen sich auf diese Weise Tests Mit dem Tool Monkey ist es möglich, zufälliges Benutzerverhalten zu simulieren, also eine (pseudo-) zufällige Folge z. B. von Gesten. durchführen, bei denen man feststellen kann, wie stabil sich die Anwendung unter Stress verhält. Ein weiteres Feature dieses Tools ist es, dass man es über die Einschränkung des Tests auf bestimmte Packages auch so konfigurieren kann, dass nur Teile der Anwendung getestet werden. Das ist vor allem dann sinnvoll, wenn von Endkunden immer wieder ein bestimmter Fehler gemeldet wird, der aber nicht reproduziert werden kann. Er kann dann eventuell mit Monkey nachgestellt werden. Für diese Situation ist es auch sinnvoll, dass man den seed, also den Startwert der Zufallszahlenfolge, angeben und so die Reihenfolge der zufällig erzeugten Events reproduzieren kann. Fazit Testen von mobilen Geräten ist eine Herausforderung, aber mit den hier vorgestellten Methoden und Tools ist es möglich, eine individuell auf Anwendungen und Unternehmen zugeschnittene Teststrategie zu entwickeln, mit deren Hilfe über Unit Tests, funktionale Entwicklertests, Abnahme- und Regressionstests und Stresstests die korrekte und zuverlässige Funktion der Anwendung weitestgehend sichergestellt werden kann. Arne Limburg ist Softwarearchitekt bei der open knowledge GmbH in Oldenburg. Er verfügt über langjährige Erfahrung als Entwickler, Architekt und Consultant im Java-Umfeld und ist auch seit der ersten Stunde im Android-Umfeld aktiv. Links & Literatur [1] [2] [3] [4] [5] android