Der Software Testing Mix für Online-Plattformen bei cloudtec

Im vorherigen Beitrag haben wir beschrieben, welche Testarten es gibt und warum der passende Mix vom Projekt abhängt. Eine Website braucht eine andere Zusammenstellung als eine Webapplikation oder eine Online-Plattform. Hier wird es konkret: Das ist der Mix, den wir in unserer eigenen Software einsetzen.

Warum wir überhaupt testen

Unsere Plattformen werden laufend weiterentwickelt und ergänzt. Genau das macht Tests notwendig: nicht der einmalige Nachweis, dass etwas funktioniert, sondern der Nachweis, dass es nach der nächsten Änderung immer noch funktioniert. Vier Punkte sind uns dabei wichtig:

• Regressionen verhindern. Neuer Code bricht bestehende Funktionen nicht unbemerkt.
• Updates absichern. Nach grösseren Framework- oder Modul-Updates ist belegt, dass die Applikation weiterhin läuft.
• Refactoring ermöglichen. Wer Code umbauen will, braucht ein Netz. Ohne Tests bleibt überholter Code stehen, weil niemand ihn anzufassen wagt.
• Qualität nachweisen. Jeder Build muss alle Tests bestehen, bevor ein Release erfolgt.

Woran wir einen guten Test messen

Nicht jeder Test rechtfertigt seinen Aufwand. Wir halten uns an vier Kriterien:

• Refactoring-resistent. Der Test läuft weiter, wenn der Code umgebaut wird. Fehlschlagen darf er erst, wenn sich das Verhalten der Funktion tatsächlich ändert.
• Schnell geschrieben, schnell gelaufen. Je aufwendiger ein Test in der Entwicklung ist, desto grösser die Chance, dass er gar nicht erst entsteht.
• Hohe Code Coverage, also ein hoher Anteil an Codezeilen, die ein Testlauf tatsächlich durchläuft und validiert.
• Genau. Falsch-positive und falsch-negative Ergebnisse kosten mehr Zeit, als sie sparen. Tests auf irrelevanten Code lassen wir weg.

Die vier Testarten in unseren Plattformen

Behat: Workflows und Berechtigungen im Browser

Behat-Tests steuern einen echten Browser und decken damit die Benutzeroberfläche samt JavaScript ab. Sie sind langsamer als alle anderen Testarten, liefern dafür die beste Code Coverage und überstehen ein Refactoring am zuverlässigsten. Wir bilden damit die Workflows innerhalb einer Plattform ab und spielen Szenarien mit Testdaten durch. Ein zweiter Einsatzzweck sind Berechtigungen: Der Test prüft, dass Inhalte und Ressourcen nur für autorisierte Benutzer sichtbar sind.

Modultests: einzelne Bausteine gegen das Framework

Modultests, auch Feature-Tests genannt, simulieren das Symfony-Framework und prüfen einzelne Klassen: einen Command, ein Mail-Template, einen Event-Listener. Ein Refactoring überstehen sie schlechter als Behat-Tests, dafür sind sie schneller geschrieben und zwingen zu sauber geschnittenem Code.

Ein Beispiel: Ein Listener schreibt einen Historieneintrag, sobald ein konfiguriertes Element angelegt oder aktualisiert wird. Behat prüft in der Oberfläche, ob der Eintrag erscheint. Der Modultest geht jede mögliche Kombination durch und stellt sicher, dass der Listener auch dann greift, wenn eine Entität über einen Command aktualisiert wird, also ganz ohne Oberfläche.

Unit-Tests: abgeschlossene Logik

Unit-Tests setzen wir dort ein, wo ein Stück Code in sich abgeschlossen ist und nicht auf andere Schnittstellen oder Funktionen zugreift. Sie laufen schnell und sind am einfachsten zu erstellen. Ein typischer Fall ist die Preisberechnung in unserem E-Commerce-Modul: Die Funktionen lassen sich isoliert durchrechnen, ohne dass ein Browser oder eine Datenbank im Spiel ist.

Smoke-Tests: kommt die Plattform überhaupt hoch?

Vor dem Rollout einer neuen Anwendung prüfen Smoke-Tests, ob Funktionen und Dienste wie geplant vorhanden sind. Bei uns sind das vor allem Route-Smoke-Tests: Der Test ruft jede verfügbare Route auf und kontrolliert, ob ein Status 200 zurückkommt.

Der zweite Einsatzort sind unsere modular aufgebauten Intranet-Plattformen. Pro Projekt wird festgelegt, welche Module aktiv sind. Die Smoke-Tests stellen sicher, dass eine neu aufgesetzte Instanz in jeder Modulkombination läuft, auch mit deaktivierten Modulen.

Was das für dein Projekt heisst

Du bekommst Plattformen, die zuverlässig laufen, und zwar nicht nur am Tag des Go-live. Welche Tests dafür nötig sind, entscheidet sich pro Projekt: Die businesskritischen Abläufe sichern wir zuerst ab, alles Weitere folgt dem Verhältnis von Aufwand und Nutzen.

In die Testing-Phase binden wir dich direkt ein. Niemand kennt die fachlichen Anforderungen besser als die Menschen, die täglich damit arbeiten.