Warum TDD+ Kontinuierliches Testen für mobile Anwendungen unerlässlich ist (Teil 1 von n)

Seit ein paar Monaten entwickle ich mobile Anwendungen, einige für das Geschäft zu Hause (eine Einkaufslisten-App für Freundinnen, die tatsächlich funktioniert, und eine Augmented-Reality-Garten-iPad-App) und einige für die Arbeit. Ich habe die Erfahrung gemacht, dass TDD und kontinuierliches Testen(Test Driven Development) eine Arbeitsweise ist, die zu weniger Fehlern und Regressionsproblemen und zu einem besseren Design meiner Software führt, es ist meine bevorzugte Art zu programmieren, nicht zu testen.

Zu Beginn möchte ich Ihnen sagen, wie ich von TDD profitiere:

1. Robust
2. Besseres Code-Design, nein wirklich!
3. Regressionsprobleme frühzeitig erkennen

und Sie können hier mehr über TDD und kontinuierliches Testen lesen. Die Sache ist die, dass ich für das Schreiben einer mobilen App etwa 20 % der Zeit benötige, die ich für das Schreiben einer web-, client- und serverbasierten App benötigen würde. Das ist natürlich sehr schön, denn so kann ich viele Apps schreiben. Es bedeutet aber auch, dass ich, wenn ich einen Fehler beheben oder eine neue Funktion hinzufügen muss, diese nach TDD entwickeln muss, da ich sonst keine Zuverlässigkeit garantieren kann. Lassen Sie mich also erklären, warum...

Bisherige Erfahrungen Die letzte komplexe Software, an der ich gearbeitet habe, ist ein Produkt namens Deployit, mit dem Java-Anwendungen auf Anwendungsservern bereitgestellt werden können, und zwar nicht nur auf einem, sondern auf vielen verschiedenen Servertypen, wobei der Bereitstellungsteil in einem so genannten Plugin gekapselt ist. Für jedes Plugin haben wir jede Menge Tests geschrieben, und sie erweisen sich als wahrer Lebensretter. Als Entwickler arbeite ich nicht nur an einem einzigen Plugin, sondern am gesamten Produkt (teilweise, weil wir ein kleines Team sind und ich das gerne tue). Das bedeutet, dass ich in einer Woche eine neue Bereitstellungslogik zu Plugin A hinzufüge und in der nächsten Woche einen Fehler in Plugin B behebe. Ich bin ein guter Programmierer mit einem guten Gedächtnis, aber die Arbeit an so vielen Plugins und die schnelle Behebung von Problemen oder das Hinzufügen von Funktionen ist schwierig. Ich muss zwischen den Feinheiten von Plugin D und der Komplexität von Plugin W hin- und herwechseln. Dabei unterlaufen mir zwangsläufig ein oder zwei Fehler, die die Veröffentlichung verzögern oder die Benutzer verärgern, weil Funktionen, die früher funktionierten, jetzt nicht mehr funktionieren. Wie lässt sich das also mit mobilen Anwendungen vergleichen? Ganz einfach: Plugins ähneln für mich Apps. In der mobilen Welt arbeiten Sie zwangsläufig in kurzer Zeit an mehreren Apps, d.h. Sie brauchen Hilfe, um diese Apps stabil zu halten, während Sie an ihnen arbeiten. Übersetzung von TDD+Continuous Testing auf die mobile Entwicklung Haben Sie schon einmal eine App aktualisiert, an der Sie vor 2 Monaten gearbeitet haben, und dabei versehentlich einige alte Funktionen zerstört? Dann haben Sie sicher gesehen, was mit Ihren Nutzerbewertungen passiert ist, sie sind abgestürzt, oder? Die Leute erwarten, dass Funktionen, die schon immer funktioniert haben, auch weiterhin funktionieren, sonst bekommen Sie 1 Stern oder schlimmer noch, die App wird gelöscht! Neue Funktionen können Fehler haben, weil sie neu sind. Bestehende Funktionen sollten einfach funktionieren, es gibt keine Entschuldigung dafür, dass das nicht der Fall ist.Es sei denn, Ihr Gehirn kann den Überblick darüber behalten, was der Code jeder App, an der Sie arbeiten, tut, was ich nicht glaube, sonst würden Sie bei der NASA an "Space Bus 3.0" arbeiten. Hier kommen Ihre automatisierten Tests ins Spiel, die Ihnen wirklich helfen, eine Korrektur vorzunehmen und zu garantieren, dass Ihre alte Funktionalität nicht kaputt geht.Es hilft Ihnen auch, neue Funktionalität robuster zu machen. Testen Sie nicht nur den Happy Flow, sondern auch den Monkey Flow, geben Sie ein paar seltsame Daten ein, lösen Sie ein paar seltsame Touch-Events aus, schauen Sie, ob Sie Ihre App zum Absturz bringen können, und machen Sie das automatisiert. Ihre App wird dadurch viel robuster und Ihre Benutzer werden Sie dafür lieben. Was kommt als Nächstes... Die obigen Worte sind alle schön und gut, aber wie machen wir das eigentlich? In den nächsten Blog-Beiträgen werde ich auf die technischen Details eingehen, wie das geht;

1. Unit-Tests (billige Tests auf Code-Ebene, OCUnit, JUnit)
2. Kontinuierliche Integration (mit Jenkins)
3. UI-Tests (nicht ganz billige Tests auf der UI-Ebene, Automatisierungs-APIs, Mock-Frameworks) und tun dies für iOS- und Android-Plattformen.