SaaS
Erst der Test, dann der Code in einer SaaS-Plattform
In der testgetriebenen Entwicklung (TDD) wird zuerst ein Test geschrieben, der scheitert, dann der Code, der ihn besteht, und zuletzt wird der Code verbessert. So hat jede Funktion einer SaaS-Plattform von Anfang an ihre Prüfung. Die meisten Tests sind klein und schnell, wenige prüfen das Ganze im Browser.
Eine SaaS-Plattform ändert sich ständig: neue Funktionen, neue Rollen, neue Kunden. Ohne automatische Prüfungen hinterlässt jede Änderung die Frage, ob etwas kaputtgegangen ist, das funktioniert hat. Wir schreiben für jede Funktion zuerst den Test und dann den Code. So ist die Prüfung kein letzter Schritt, der ausfallen kann, sondern der Punkt, an dem die Arbeit beginnt.
Was ist testgetriebene Entwicklung?
Testgetriebene Entwicklung, bekannt als TDD (test-driven development), ist eine Methode, bei der der Test vor dem Code geschrieben wird, den er prüft. Martin Fowler beschreibt sie in drei Schritten. Man schreibt einen Test für die nächste Funktion, man schreibt den Code, bis er besteht, und man verbessert den neuen und den alten Code, damit er gut gebaut ist.
Die drei Schritte wiederholen sich in einem Zyklus, bekannt als Red-Green-Refactor: Der Test scheitert (red), er besteht (green), und der Code wird aufgeräumt (refactor). Fowler ergänzt, dass vor Beginn des Zyklus eine Liste der zu prüfenden Fälle geschrieben wird und jeweils ein Fall bearbeitet wird. Die Methode betrifft nicht speziell Plattformen, zahlt sich dort aber am meisten aus, weil sie viele Jahre leben und sich ständig ändern.
Warum wird der Test zuerst geschrieben?
Der Test wird zuerst geschrieben, weil er so beweist, dass er scheitern kann. Ein Test, der nach dem Code entsteht, besteht oft gleich beim ersten Mal, und niemand weiß, ob er je einen Fehler finden würde. Wenn wir ihn zuerst scheitern sehen, wissen wir, dass er wirklich etwas prüft.
Es gibt einen zweiten Vorteil. Um den Test zu schreiben, muss die Funktion genau beschrieben werden: was sie annimmt, was sie zurückgibt, was passiert, wenn etwas schiefgeht. Das zeigt früh, was in den Anforderungen fehlt, wenn die Korrektur eine Rückfrage kostet und keinen Umbau. Darum passt die Methode zur Anforderungsanalyse vor dem Code.
Welche Tests braucht es, und wie viele?
Es braucht viele kleine Tests und wenige große. Das ist die Idee der Testpyramide (test pyramid), wie Fowler sie formuliert: deutlich mehr Tests auf niedriger Ebene als Tests, die über die Oberfläche laufen. In der Mitte liegt eine Ebene von Tests, die die Anwendung über ihre Dienstebene prüfen.
Ebene | Was geprüft wird | Wie viele |
|---|---|---|
Kleine Tests | Eine Regel oder eine Berechnung, einzeln | Die meisten |
Dienst-Tests | Eine Funktion über die Dienstebene der Anwendung | Mittlere Anzahl |
Oberflächen-Tests | Ein vollständiger Nutzerweg im Browser | Die wenigsten |
Fowler erklärt, warum Oberflächen-Tests wenige sein sollen: Sie sind empfindlich, teuer im Schreiben und langsam in der Ausführung. Er nennt aber auch eine Ausnahme. Sind die Tests auf hoher Ebene schnell, zuverlässig und billig zu ändern, braucht es die auf niedriger Ebene nicht. In der Praxis bilden wenige Tests die echte Nutzung nach, und die kleinen leisten den größten Teil der Arbeit.
Wie arbeiten wir in einer Plattform?
Wir folgen bei jeder Funktion derselben Reihenfolge. Sie ist kurz und wird immer eingehalten:
Die Anforderung wird geschrieben und freigegeben. Jede Funktion stammt aus den schriftlichen Anforderungen der ersten Phase.
Der Test wird geschrieben und scheitert. Wir prüfen, dass er aus dem richtigen Grund scheitert.
Der Code wird geschrieben, bis der Test besteht. Es wird nichts geschrieben, was kein Test verlangt.
Der Code wird aufgeräumt. Nach jeder Änderung laufen die Tests erneut.
Die Funktion wird im Browser geprüft. Wir öffnen sie als Nutzer und vergleichen sie mit dem freigegebenen Entwurf.
Jede Phase geht erst weiter, wenn alle Prüfungen bestanden sind. Unser Werkzeug Planner wendet diese Reihenfolge an, wenn es aus einer schriftlichen Spezifikation eine Anwendung baut, und wir beschreiben das in der Fallstudie zu Planner. Wichtig ist, dass die Tests nicht gelockert werden, damit sie bestehen: Scheitert eine Prüfung, wird der Code korrigiert.
Wie sieht ein Test in der Praxis aus?
Ein Test ist ein Satz aus den Anforderungen, so geschrieben, dass ein Programm ihn prüfen kann. Wenn die Rechtetabelle sagt, dass ein Sachbearbeiter keine Anträge genehmigt, startet der Test als Sachbearbeiter, versucht einen Antrag zu genehmigen und erwartet eine Ablehnung. Bevor der Code geschrieben ist, scheitert der Test, weil die Ablehnung noch nicht existiert.
Dann wird der Code geschrieben, der die Genehmigung ablehnt, und der Test besteht. Ändert später jemand die Regel versehentlich, scheitert derselbe Test sofort, noch bevor die Änderung Nutzer erreicht. So bleiben die Anforderungen, die Sie freigegeben haben, auch nach der Übergabe aktiv und stehen nicht nur auf dem Papier.
Was passiert, wenn ein Fehler gefunden wird?
Wird ein Fehler gefunden, schreiben wir zuerst einen Test, der ihn nachstellt. Der Test scheitert vor der Korrektur und besteht danach. So kann derselbe Fehler nicht zurückkehren, ohne dass eine Prüfung ihn findet, und jede Korrektur hinterlässt einen dauerhaften Schutz.
Das gilt auch für alles, was das Agententeam findet, das das fertige Projekt auf Fehler, Bedienbarkeit und Sicherheit prüft. Jeder bestätigte Befund wird auf dieselbe Weise behoben. Das Vorgehen erklären wir in der Fallstudie zu den Qualitäts- und Sicherheits-Agenten. Ein gutes Beispiel ist die Sicherheit der Rechte, die wir im Artikel über Rollen und Rechte in einem SaaS beschreiben.
Häufig gestellte Fragen: Erst der Test, dann der Code in einer SaaS-Plattform
Macht TDD das Projekt langsamer?
Am Anfang braucht jede Funktion etwas mehr Zeit, weil auch ihre Prüfung geschrieben wird. Diese Zeit wird später eingespart, wenn Änderungen automatisch geprüft werden und nicht von Hand. Bei einer Plattform, die sich über Jahre ändert, ist der Gewinn klar.
Braucht jede Plattform Tests?
Je komplexer und langlebiger eine Plattform ist, desto mehr braucht sie Tests. Bei einem kleinen internen Werkzeug genügt eine weniger dichte Prüfung. Wie viel genau, wird in den Anforderungen vereinbart und im Projektumfang festgehalten.
Ersetzen automatische Tests die Prüfung durch Menschen?
Nein. Automatische Tests finden die Fehler, die sich vorher beschreiben lassen. Darum prüfen wir auch im Browser, als Nutzer, und testen das Ergebnis in echten Szenarien aus Ihrem Arbeitsalltag. Beides ergänzt sich.
Was heißt es, dass alle Prüfungen bestanden sind?
Es heißt, dass kein Test scheitert und dass die Funktion auch im Browser geprüft wurde. Nur dann gehen wir zum nächsten Schritt, damit ein Fehler nicht weitergetragen wird. Was die Übergabe genau umfasst, steht im Projektumfang, den Sie am Anfang freigeben.
Möchten Sie eine Plattform, die von Anfang an geprüft wird?
Wenn Sie ein SaaS-Produkt oder eine interne Plattform planen und wissen wollen, wie jede Funktion geprüft wird, beschreiben Sie Ihr Projekt in der Projektanfrage. Wir besprechen die Tests gemeinsam in der Phase der Anforderungen. Sehen Sie sich auch die Seite zu den SaaS-Plattformen an.