Wir schreiben das Jahr 2017: Testautomatisierung ist bei der Entwicklung mobiler Apps keine Option!

Hinweis: Obwohl sich dieser Beitrag auf die Entwicklung mobiler Apps mit Xamarin konzentriert, gilt er auch für andere native mobile Apps, die in Swift, Java oder sogar Web-Apps entwickelt wurden. Es ist 2017! Was auch immer Sie bauen, beginnen Sie mit der Testautomatisierung! Als Berater bei xebia habe ich mit vielen verschiedenen Kunden zu tun, denen ich mit meinem Fachwissen über die Entwicklung mobiler Anwendungen helfe, ihre mobilen Anwendungen zu verbessern. Im vergangenen Jahr ist mir aufgefallen, dass Continuous Delivery ein heißes Thema ist und Unternehmen und Teams sich darauf konzentrieren, ihre Apps automatisch über Hockeyapp an ihre Tester oder sogar an die Stores in der Beta- und/oder Produktionsphase zu verteilen. In agilen Szenarien (und mal ehrlich, wer macht das derzeit nicht? Jedes Unternehmen oder Projekt, das ich besuche, gibt an, agil zu sein oder Scrum zu praktizieren, obwohl einige nur tägliche Releases durchführen und das Scrum nennen). In der heutigen Welt ist es wirklich wichtig, dass Sie häufig neue Produkte herausbringen können, denn Sie wollen sich an die Bedürfnisse Ihrer Kunden anpassen können, die sich fast immer ändern und weiterentwickeln.

Implementierung eines Shift Left Qualitätsmodells

Testautomatisierung ist ein Prozess, der nicht nur den Entwicklern oder Testern vorbehalten ist. Es ist etwas, das jeder im Kopf haben muss, vom Product Owner über den Entwickler bis zum Tester. Automatisierte Tests können Ihnen helfen, den Aufwand für Regressionstests zu verringern, aber die Investition in Testautomatisierung kann Ihnen wirklich helfen, den Fokus auf Qualität früher im Entwicklungsprozess Ihrer Anwendung zu legen.

Traditionelles Qualitätsmodell

Im traditionellen Qualitätsmodell findet die meiste Aufmerksamkeit für Qualität in den Phasen NACH der Entwicklung statt. Dieses Muster stammt noch aus der Wasserfall-Ära und funktioniert bei kurzen Iterationen nicht so gut. Wann werden Sie testen oder überprüfen, ob Sie die Erwartungen Ihrer Stakeholder erfüllen? Qualitätsprobleme werden in den letzten Tagen des Sprints auftauchen und es bleibt kaum Zeit, sie im laufenden Sprint zu beheben. Das passiert in vielen Unternehmen, die ich besuche. Schauen wir uns also an, was wir tun sollten, um dies zu verbessern. Nach links schieben Qualitätsmodell Wie können wir also diese Verschiebung nach links vornehmen und ein früheres Feedback über die Qualität der von uns entwickelten Software erhalten? Ein häufiger Fallstrick, den ich bei Unternehmen sehe, ist, dass sie sich nur auf die Bereitstellung konzentrieren und dann manuell testen, was oft dazu führt, dass eine Menge Funktionen einen Sprint nach der eigentlichen Entwicklung getestet werden.

Agile Test-Pyramide

Die Agile Testpyramide ist ein Konzept, das von Mike Cohn entwickelt wurde. Sie gibt eine gute Beschreibung, wie Ihre automatisierte Testlandschaft für jede Art von Anwendung aussehen sollte. Das Software Testing Cupcake-Antimuster ist oft eine umgedrehte Agile Testpyramide oder einfach nur 3 verschiedene Teams, die nicht zusammenarbeiten und ihre eigenen Tests erstellen. Nach einigen Releases und Regressionstests, die immer mehr Zeit in Anspruch nehmen, beginnen die Teams, in die Testautomatisierung zu investieren und ihre manuellen Tests zu automatisieren, indem sie automatisierte UI-Tests schreiben. Das mag eine Zeit lang funktionieren, aber automatisierte UI-Tests sind sehr teuer in der Erstellung, brechen häufig ab und geben nur wenig Aufschluss darüber, was genau schief läuft. Es kann schwierig sein, diese Tests auf dem neuesten Stand zu halten, wenn sich die Benutzeroberfläche häufig ändert, und außerdem dauert die Ausführung ziemlich lange.

Einheitstests

Die Agile Testpyramide legt den Schwerpunkt auf eine solide Basis von Unit-Tests. Obwohl sich Unit-Tests nicht auf die End-to-End-Szenarien konzentrieren, die die manuellen Tester ausführen könnten, haben sie eine Menge Vorteile gegenüber automatisierten UI-Tests: Sie sind kostengünstig zu erstellen und zu pflegen, geben wirklich exakte Fehlermeldungen aus, wenn ein Teil des Codes nicht wie erwartet funktioniert, und vor allem sind sie schnell (oder sollten es sein). Ein weiterer Vorteil von Unit-Tests ist, dass sie eine ordnungsgemäße Isolierung von Abhängigkeiten gewährleisten, was zu einer saubereren Softwarearchitektur führt. Ich habe an vielen Projekten teilgenommen, bei denen ich gebeten wurde, bei der Erstellung von Unit-Tests für eine bestimmte Software zu helfen, die voller Spaghetti-Code war, der das Schreiben von Tests fast unmöglich machte. Wenn Sie von Anfang an Unit-Tests schreiben, während Sie den Code Ihrer Anwendung schreiben (vorzugsweise sogar im TDD-Stil), wird dies mit Sicherheit zu saubererem und besser testbarem Code führen. Ein Beispiel für schnelles Feedback ist die Live-Unit-Testing-Funktion von Visual Studio 2017, mit der Sie sofort Feedback zu Ihren Unit-Tests sehen, während Sie Ihren Code bearbeiten.

In meiner Rolle als Berater werde ich oft gebeten, einige Richtlinien und Regeln für Unit-Tests aufzustellen. Mein Ansatz ist, dass es nicht funktioniert, einfach nur bestimmte Regeln für Unit-Tests aufzustellen. Dadurch konzentrieren sich die Entwickler zu sehr auf diese Regeln und nicht auf den eigentlichen Zweck: die Entwicklung besserer Software. Ein Beispiel dafür ist die Festlegung von Regeln für die Codeabdeckung. Eine Frage, die oft gestellt wird, lautet: "Sollen wir eine Regel für die Codeabdeckung von 80 / 90 / 100% aufstellen?" Dies führt oft dazu, dass Entwickler diese Zahl der Codeabdeckung anstreben und denken, dass sie fertig sind, wenn sie dieses "Ziel" erreichen. Wenn Sie eine Codeabdeckung von 80% erreichen können, indem Sie nur den gesamten einfachen Code testen und 20% des komplexen Codes ungetestet lassen, verfehlen Sie eindeutig den Sinn, warum wir Unit-Tests schreiben.

"Sollen wir eine Regel für die Codeabdeckung auf 80 / 90 / 100% festlegen?" Dies führt oft dazu, dass Entwickler diese Zahl der Codeabdeckung anstreben und denken, dass sie fertig sind, wenn sie dieses "Ziel" erreicht haben.

Die einzige Möglichkeit, Unit-Tests für Ihr Team nutzbar zu machen, besteht darin, dass das gesamte Team davon überzeugt ist, dass das Schreiben von Unit-Tests gut für das Team ist und es ihm die Möglichkeit gibt, Änderungen am bestehenden Code einfacher vorzunehmen, was Zeit und Geld spart. Wenn Sie eine stabile Basis der Testpyramide aus Unit-Tests aufbauen, stellen Sie sicher, dass diese Tests schnell laufen und keine externen Abhängigkeiten haben. Wenn Tests langsam werden, wird nur eines passieren: Die Leute werden aufhören, sie auszuführen, und der ganze Wert geht verloren. Wenn Sie eine gute Software-Architektur aufbauen, die sich auf eine lose Kopplung konzentriert, z.B. durch die Verwendung von Dependency Injection, wird Ihr Code viel einfacher zu testen sein, weil es auch einfacher ist, Mocks für Ihre Abhängigkeiten zu erstellen. Welche Art von Tools bevorzuge ich also?

Unit Testing Tools

In der Microsoft-Landschaft gibt es einige Varianten von Unit-Test-Frameworks. MSTest, NUnit und XUnit sind die Frameworks, die am häufigsten verwendet werden. Es gibt viele Gemeinsamkeiten zwischen ihnen, aber ich denke, dass die meisten Leute derzeit entweder NUnit oder XUnit verwenden. Ich persönlich bevorzuge XUnit, aber es gibt hier keinen wirklichen Gewinner. Neben einem Unit-Testing-Framework ist es auch praktisch, ein Mocking-Framework zu haben. Es gibt mehrere Mocking-Frameworks. Ich bevorzuge hier MOQ, aber wenn Sie mit anderen Frameworks vertraut sind, bleiben Sie einfach bei diesen. Andere beliebte Mocking-Frameworks sind: FakeItEasy oder NSubstitute. Stacy Gay hat einen schönen Artikel über diese oben beschriebenen Tools mit dem Titel "The holy Trinity of C# Unit Testing"(Die heilige Dreifaltigkeit von C# Unit Testing) geschrieben. Eine weitere Sache, die Sie sich ansehen sollten, ist Fluent Assertions , um sehr schön lesbare Assertions in Ihren Tests zu erstellen.

Service-Tests

Servicetests werden oft als "Integrationstest" bezeichnet. Ich mag den Namen Integrationstest nicht, weil die Leute nur an das Testen von APIs oder Webservices denken. Servicetests können Tests sein, die mehrere Einheiten innerhalb eines Inhalts integrieren oder die tatsächliche Integration zwischen verschiedenen Komponenten in Ihrer Anwendungslandschaft durchführen. Für die erste Art von Servicetests können Sie einfach dieselben Tools wie für Ihre Unit-Tests verwenden. Integrationstests über alle Ihre Anwendungsschichten hinweg, von der App über die API bis zum Backend, können aufgrund der Verbindungen zu Systemen und Testdaten recht kompliziert sein. Ein Ratschlag könnte sein, mit Containern zu experimentieren, in denen Ihr Test-Backend ausgeführt wird, damit es einfacher ist, seinen Zustand zwischen den Tests zurückzusetzen. Wenn Sie Tests für Ihre UI-Komponenten erstellen möchten, kann Ihnen die "Spezifikation nach Beispiel" wirklich dabei helfen, die richtige Anwendung zu erstellen, die Ihr Produktverantwortlicher wirklich wollte. Bei der Entwicklung von Xamarin-Anwendungen ist das MVVM-Muster das Designmuster, das in 99% aller Anwendungen, die ich kenne, für den Aufbau Ihrer UI-Logik verwendet wird. Ich liebe das MVVM-Muster, weil es das Testen Ihrer UI-Logik in Ihren Viewmodels wirklich einfach macht. Wenn Sie noch keine Erfahrung mit MVVM haben, sehen Sie sich diese Folge der Xamarin Show von James Montemagno an.

Spezifikation am Beispiel

Specification by example ist eine Technik, die in der verhaltensorientierten Entwicklung verwendet wird und sich darauf konzentriert, das Richtige zu bauen. Wie oft haben Sie schon eine neue Funktion gezeigt und Ihr Produktverantwortlicher hat Sie gefragt: "Kann das auch so funktionieren?", "Was passiert in Szenario X?". Ups, daran haben Sie nicht gedacht... An dieser Stelle kommt die Spezifikation nach Beispielen ins Spiel. Specification by Example besagt, dass Sie Ihre Spezifikationen so erstellen sollten, dass Sie alle Szenarien in Beispielen beschreiben. Diese Beispiele sollten nicht vom Produkteigentümer oder Tester erstellt werden. Dies ist eine Teamleistung. Wenn Sie agil arbeiten, haben Sie wahrscheinlich schon von den 3 Amigos (BA, Tester und Entwickler) gehört. Während der Verfeinerung sollten sie zusammenarbeiten, um alle verschiedenen Szenarien auszuarbeiten. Diese Szenarien können dann in einer bestimmten DSL namens Gherkin niedergeschrieben werden. Das Tolle daran ist, dass Sie damit automatisierte Tests erstellen können, die Ihre Spezifikationen ausführen. Ihr Produktverantwortlicher wird sehen, dass die Texte, die er als Spezifikationen geschrieben hat, zu grünen Tests werden. Und was ist mit den Fragen, die ich vorhin erklärt habe? Nun, die einfache Antwort lautet, dass Sie in jedem Fall ein weiteres Szenario hinzufügen müssen. Wenn Sie in Beispielen denken, werden Sie die meisten Szenarien beim ersten Mal gut abdecken, aber es kann immer vorkommen, dass Sie einige übersehen haben. fügen Sie einfach ein weiteres Szenario und damit einen weiteren Test hinzu und schon sind Sie startklar! Nachfolgend finden Sie ein Beispiel, das in Gherkin geschrieben ist: In .Net können Sie Specflow verwenden, um Gherkin in automatisierte Tests zu verwandeln. Specflow erstellt für jede Zeile Ihrer Spezifikationsdatei eine Testmethode, die als Schritt bezeichnet wird. Innerhalb dieses Schritts können Sie die Aktionen ausführen, die Sie von der Anwendung erwarten würden. Die Given When Then-Syntax funktioniert hervorragend zusammen mit Arrange, Act Assert, die Sie von Unit-Tests gewohnt sind. In den Given-Schritten führen Sie Ihre Arrangements aus, in den When-Schritten Ihre Actions und im Then-Schritt können Sie Ihre Assertions ausführen. Das funktioniert sehr gut mit Xamarin, das diese Tests auf Ihren Viewmodels ausführt. Sie können auch noch einen Schritt weiter gehen und automatisierte UI-Tests in Kombination mit Specification by example schreiben.

Automatisierte UI-Tests

Wir haben fast die Spitze der Testpyramide erreicht und der nächste Schritt sind automatisierte UI-Tests. Ein häufiger Fehler ist es, sich zu sehr auf Ihre UI-Tests zu konzentrieren, ohne eine gute Grundlage für Unit-Tests zu haben. Automatisierte UI-Tests sehen wie eine wirklich gute Lösung aus, um Ihre manuellen Tests zu automatisieren, aber es ist immer eine Kombination aus diesen + Unit-Tests. Automatisierte UI-Tests sind oft sehr wartungsintensiv, wenn Sie Ihre Backends nicht weglassen. Und UIs können ziemlich schwer zu ändern sein, und dann müssen auch Ihre Tests oft geändert werden. UI-Tests geben auch nur sehr wenig Aufschluss darüber, ob etwas nicht wie vorgesehen funktioniert. Sie erhalten lediglich die Rückmeldung, die auch ein Benutzer erhalten würde, zum Beispiel: "Wenn ich diese Taste drücke, sollte die Liste neu geladen werden". Wenn etwas nicht richtig funktioniert, müssen Sie immer noch herausfinden, wo genau Ihr Code nicht richtig funktioniert: Hallo Unit-Tests! Automatisierte UI-Tests haben einige wirklich gute Vorteile, vor allem in der mobilen Welt. Die Landschaft der mobilen Geräte ist sehr vielfältig, mit Tausenden von verschiedenen Geräten mit unterschiedlichen Kombinationen von Betriebssystemversionen und Bildschirmgrößen. Xamarin test cloud ist ein wirklich guter Weg, um zu testen, ob Ihre App wirklich auf all diesen Geräten funktioniert. Xamarin test cloud funktioniert auch hervorragend in Kombination mit verhaltensgesteuerter Entwicklung und Spezifikation nach Beispielen. Sie können Ihre Spezifikationen ganz einfach in Gherkin erstellen und Specflow mit Xamarin UI Tests verbinden. Ich habe letzten Dezember einen Xamarin-Universitätsvortrag zu diesem Thema gehalten.

Die Xamarin Test Cloud gibt Ihnen zusammen mit Specification by example ein hervorragendes Feedback darüber, wie Ihre Spezifikationen auf tatsächlichen Geräten aussehen. Werfen Sie einen Blick auf die Spezifikationen auf der linken Seite und dann erhalten Sie einen Screenshot davon, wie die App bei jedem Schritt aussieht.

Manuelle Sondierungstests

An der Spitze der Pyramide stehen die Sondierungstests. Dies ist etwas, das Sie nicht automatisieren können. Obwohl es sich hierbei um manuelle Tests handelt, geht es bei diesen Tests nicht darum, ein Testskript zu schreiben und jedes Mal alle Schritte zu befolgen, wenn Sie diese Tests ausführen (das ist einfach nur das alte manuelle Testen). Es geht auch nicht darum, wie verrückt herumzuklicken, um zu sehen, was passiert. Das nennt man Monkey Testing :). Beim explorativen Testen geht es darum, nach Randfällen zu suchen und zu sehen, was dort passiert. Ein Beispiel könnte sein: Was passiert, wenn Sie die Mobilfunkverbindung auf halbem Weg zum Laden der Artikelliste unterbrechen, oder was passiert, wenn ich einen Anruf erhalte, während ich meine App verwende. Diese Tests sind wirklich schwer zu automatisieren, aber sie sind für Ihr Entwicklungsteam von großem Wert.

Packen Sie ein: Wir schreiben das Jahr 2017. Beginnen Sie mit der Implementierung von Testautomatisierung in Ihren Anwendungen!

Ich hoffe, dieser Beitrag hat Sie dazu inspiriert, mit der Automatisierung Ihrer Tests innerhalb des Lebenszyklus Ihrer App-Entwicklung zu beginnen. Wenn Sie Anmerkungen zu Tools oder Praktiken haben, die ich in diesem Beitrag übersehen habe (natürlich kann ich sie nicht alle aufzählen), können wir hoffentlich nach 2017 zurückblicken und sehen, dass immer mehr Menschen den Geist der Testautomatisierung annehmen. Happy Coding! Geert van der Cruijsen The post Es ist 2017: Testautomatisierung ist bei der Entwicklung mobiler Apps keine Option! appeared first on Mobile First Cloud First.