Automatische Tests und CI

01Was das ist

Ein automatischer Test ist ein kleines Programm, das die Anwendung bedient und das Ergebnis prüft. Er legt etwa eine Rechnung mit drei Positionen an und prüft die Summe, meldet sich als Kunde an und prüft, dass nur dessen Tickets erscheinen, oder gibt ein falsches Passwort ein und prüft, dass die Anmeldung es abweist.

All das könnte ein Mensch von Hand tun, und vor einer Veröffentlichung tut es oft auch jemand. Der Unterschied liegt in Tempo und Wiederholung. Eine Sammlung von mehreren hundert Prüfungen läuft in wenigen Minuten, jedes Mal gleich, so oft wie nötig. Jede neue Funktion bringt ihre eigenen Tests mit, die Sammlung wächst mit der Anwendung und prüft auch Funktionen weiter, die längst fertig sind.

02Drei Arten von Tests

Tests werden meist danach eingeteilt, wie viel der Anwendung sie auf einmal abdecken:

Unit-Tests prüfen ein kleines Stück für sich, etwa die Funktion, die die Umsatzsteuer berechnet oder ein Datum formatiert. Sie laufen in Millisekunden, und ein Projekt hat meist viele davon.
Integrationstests prüfen, ob mehrere Teile zusammenspielen, zum Beispiel, ob beim Speichern eines Tickets die richtigen Zeilen in der Datenbank landen und festgehalten wird, wer die Änderung gemacht hat.
End-to-End-Tests steuern einen echten Browser durch die Anwendung wie ein Nutzer: Seite öffnen, klicken, tippen, absenden, lesen, was erscheint. Sie sind am langsamsten und am nächsten an der echten Nutzung, deshalb setzt man sie für die wichtigsten Wege ein, etwa die Anmeldung oder den Versand einer Rechnung.

03Continuous Integration

Tests helfen nur, wenn sie auch laufen. Dafür sorgt Continuous Integration, kurz CI. Jedes Mal, wenn ein Entwickler eine Änderung als Pull Request vorschlägt, nimmt ein eigener Server den Code, installiert ihn von Grund auf und führt eine feste Folge von Prüfungen aus. Diese Folge heißt Pipeline.

Eine typische Pipeline prüft mehr als nur die Tests:

Die Typprüfung stellt sicher, dass jeder Wert die Art von Daten hat, die der Code erwartet. In TypeScript-Projekten fängt sie viele Fehler ab, bevor überhaupt ein Test läuft.
Die Stilprüfung, oft Linting genannt, setzt die Regeln des Teams für die Schreibweise des Codes durch und markiert typische Fehler.
Die Tests laufen: Unit, Integration und, wo eingerichtet, End-to-End.
Der Build übersetzt die ganze Anwendung so, wie sie ausgeliefert würde. Lässt sie sich nicht bauen, kann sie nicht live gehen.

04Was passiert, wenn eine Prüfung fehlschlägt

Das Ergebnis erscheint am Pull Request als grüner Haken oder rotes Kreuz, mit einem Link zum genauen Schritt und zur Meldung. Das Repository ist so eingerichtet, dass eine Änderung mit rotem Kreuz nicht übernommen werden kann. Der Autor behebt das Problem, lädt die Korrektur hoch, und die Pipeline läuft erneut.

So wird Qualität zu einer Regel, die für alle gilt. Niemand muss daran denken, die Tests zu starten, und eine Änderung, die eine bestehende Funktion kaputt macht, wird gestoppt, bevor sie die Menschen erreicht, die mit der Anwendung arbeiten.

05Ein Beispiel aus einer Geschäftsanwendung

Nehmen wir ein Kundenportal, in dem Kunden Support-Tickets anlegen und ihre Rechnungen sehen. Ein Entwickler ergänzt einen Filter, mit dem Mitarbeiter Tickets nach Priorität anzeigen. Der neue Code funktioniert, und der Filter sieht im Browser richtig aus.

In der Pipeline schlägt ein älterer Integrationstest fehl. Er prüft, dass ein im Portal angemeldeter Kunde nur die Tickets seines eigenen Unternehmens sieht. Der neue Filter fragte die Datenbank ohne die Bedingung für das Unternehmen ab, und bei einer bestimmten Kombination von Filtern hätte ein Kunde die Tickets eines anderen Unternehmens sehen können. Das rote Kreuz verhindert die Übernahme, der Entwickler ergänzt die fehlende Bedingung, und der Test besteht.

Ohne den Test hätte das ein Kunde entdeckt, oder niemand. Mit ihm hat der Fehler ein paar Minuten gekostet.

06Alternativen und Grenzen

Die Alternative zu automatischen Tests ist manuelles Testen: Vor jeder Veröffentlichung arbeitet jemand eine Checkliste ab. Das ist wertvoll, um zu beurteilen, wie sich etwas bedienen lässt, und um zu finden, woran niemand gedacht hat. Es ist aber langsam, fällt unter Zeitdruck weg und erfasst selten Funktionen, die mit der Änderung scheinbar nichts zu tun haben.

Auch automatische Tests haben Grenzen. Sie prüfen nur, wofür jemand einen Test geschrieben hat, und ein Test kann selbst falsch sein. Eine grüne Pipeline heißt, dass die bekannten Anforderungen weiter erfüllt sind. Sie beweist nicht, dass die Software fehlerfrei ist. Deshalb verbinden wir Tests mit einer Prüfung jeder Änderung und damit, dass Sie neue Funktionen ausprobieren, bevor sie als fertig gelten.

Verbreitete CI-Dienste sind GitHub Actions, GitLab CI und Jenkins. Sie unterscheiden sich darin, wo sie laufen und wie man sie einrichtet. Das Prinzip ist bei allen gleich.

07Worauf Sie beim Einkauf achten sollten

Tests sind leicht versprochen und von außen schwer zu sehen. Diese Fragen helfen:

Gibt es eine Testsammlung, und läuft sie bei jeder Änderung automatisch?
Lässt sich eine Änderung übernehmen, wenn Tests fehlschlagen? Die Antwort sollte Nein lauten.
Sind die wichtigsten Wege abgedeckt: Anmeldung, Berechtigungen, alles, was mit Geld zu tun hat?
Werden Tests und Pipeline mit dem Code übergeben, sodass sie nach Projektende weiterlaufen?

08Wie wir sie nutzen

Unsere CI läuft auf GitHub Actions. Bei jedem Pull Request prüft sie die Typen, den Codestil und die Tests und ob sich die Anwendung bauen lässt. Eine Änderung mit fehlgeschlagener Prüfung kann nicht übernommen werden.

Jeder Auftrag nennt, was am Ende erfüllt sein muss, und daraus werden Tests. Änderungen an Anmeldung, Berechtigungen oder Passwörtern bekommen zusätzlich eine eigene Sicherheitsprüfung, bevor sie übernommen werden. Tests und Pipeline gehören zum Code, den Sie bei der Übergabe bekommen, und laufen in Ihrem eigenen GitHub-Konto weiter.

Häufige Fragen

Machen Tests ein Projekt teurer?

Sie zu schreiben kostet während der Entwicklung Zeit. Später sparen sie mehr, als sie gekostet haben, weil Fehler wenige Minuten nach ihrer Entstehung auffallen und sich eine bestehende Anwendung ändern lässt, ohne alles von Hand nachzuprüfen.

Heißt eine grüne Pipeline, dass es keine Fehler gibt?

Nein. Sie heißt, dass alles, wofür es einen Test gibt, weiter funktioniert. Fehler in Situationen, für die niemand einen Test geschrieben hat, bleiben möglich. Deshalb wird jede Änderung zusätzlich geprüft, und Sie probieren neue Funktionen selbst aus.

Muss ich etwas tun, damit die Tests weiterlaufen?

Nein. Die Pipeline läuft in Ihrem GitHub-Konto von selbst bei jeder vorgeschlagenen Änderung. Das übliche kostenlose Monatskontingent von GitHub Actions reicht für die meisten kleineren Anwendungen.

Kann ich die Testergebnisse sehen?

Ja. Jeder Pull Request auf GitHub zeigt für jede Prüfung einen grünen Haken oder ein rotes Kreuz, und die Details lassen sich ohne Programmierkenntnisse öffnen.

Testen Sie trotzdem noch von Hand?

Ja. Wir klicken uns durch jede neue Funktion, bevor sie zu Ihnen geht, und Sie probieren sie aus, bevor sie als fertig gilt. Automatische Tests übernehmen die Wiederholung. Ob sich etwas richtig bedienen lässt, beurteilen Menschen.