Planung von Tests

Einleitung

Tests entwerfen ist eine einfache Sache, solange es sehr wenige Tests sind. Wird der zu testende Code aber umfangreicher, lohnt es sich, sich Gedanken zu machen, wie man die Aufgabe am besten löst. Tests sollten folgende Bedingungen erfüllen:

• Verlässlichkeit: Es sollten alle Fehler erkannt werden, aber false positives vermieden werden
• Wiederholbarkeit: Eigentlich eine Sache, die sich von selbst versteht, trotzdem der Vollständigkeit halber: Bei gleicher Ausgangssituation und gleichen Eingaben muss auch dasselbe Ergebnis heraus kommen.
• Vollständigkeit: Es sollte alles getestet werden, was nötig ist. Gerade bei Akzeptanz-Tests ist das eine Herausforderung, denn hier wird oft mit Code-/Programmteilen interagiert, die nicht zum eigentlichen Code gehören. Da müssen auch alle "Rahmenbedingungen" der Programmteile erfasst werden, die für diese Testreihe nötig sind.
• Schnelligkeit: Damit Tests gerne und oft verwendet werden, sollen sie schnell sein.
• Unabhängigkeit der Tests: Tests dürfen nicht voneinander abhängen! Wenn ein Test in einer Testreihe fehlschlägt, dann darf das keine Auswirkungen auf die weiteren Tests haben. Damit sorgt man dafür, dass die Testergebnisse verlässlich sind. Folgefehler werden ausgeschlossen und man erhält gleichzeitig genauere Rückmeldung, wo was schief läuft.
• Nur ein Item pro Test. Das ist etwas Definitionssache und muss gegebenenfalls für den nächsten Punkt passend definiert werden.
• DRY - Don't Repeat Yourself! Auch bei den Tests sollte natürlich im Hinblick auf die Wartbarkeit und Erweiterbarkeit der Tests mehrfach derselbe Code vermieden werden. Das lässt sich nicht immer machen, gerade bei Akzeptanz-Tests muss gelegentlich derselbe Test mit unterschiedlichen Parametern von außerhalb durchlaufen werden.

Planung der Tests

Die hier beschriebene Vorgehensweise ist vielleicht nicht das Nonplusultra, aber mir hilft es enorm. Dabei entspricht die Reihenfolge im Großen und Ganzen auch dem Ablauf, wie die Tests am besten geplant werden. Allerdings kann man davon ausgehen, dass alle Schritte immer wieder überarbeiten werden müssen, weil in den Arbeitsschritten später Erkenntnisse kommen, die man einfach vorher noch nicht berücksichtigen kann. So kann man zum Beispiel die Bestimmung der Startpunkte erst dann als abgeschlossen betrachten, wenn wirklich alle Tests notiert und gruppiert sind.

Das ist eine iterative Vorgehensweise ganz im Sinne der agilen Programmierung.

Startpunkte der Tests bestimmen

Hier werden die Basis-Datenbestände der Testdaten definiert. Diese bestehen aus Ordnern, Dateien, Datenbanken, Tabellen und Daten in den Tabellen.

Während die Tests laufen, werden diese Daten natürlich manipuliert. Folglich muss man dafür sorgen, dass für jeden einzelnen Test immer wieder dieselbe Ausgangssituation verfügbar ist. Das ist insbesondere wichtig, wenn ein vorausgegangener Test fehlschlägt (Unabhängigkeit der Tests).

Zur Bestimmung, wie viele Startpunkte es für die Testreihen gibt, also wie viele Basis-Datenbestände man braucht, hilft es, zu überlegen, bei welchen Tests Ordner, Dateien oder Tabellen hinzu kommen. Die Wiederherstellung solcher Ausgangszustände ist aufwändiger, als wenn nur dafür gesorgt werden muss, dass die verwendeten Tabellen immer dieselben Ausgangsdaten haben.

Im Beispiel ist das ein Datenbestand, der den Abonnenten, der während der Tests verwendet wird, nicht bei den bereits vorhandenen Abonnenten ist. Außerdem wird dafür gesorgt, dass die Optionen von Komponente und der beiden Plugins immer einen definierten Ausgangszustand haben.

Warum mehrere Startpunkte?

Tests sollen so schnell wie möglich laufen, damit sie auch gerne verwendet werden!

Da die meisten Tests zur Funktionalität nicht nur am Stück laufen sondern auch für Tests von Teilbereichen verwendet werden, macht es wenig Sinn, immer auch die Installation mit zu testen. Daher lege ich bei den Tests gerne mehrere Startpunkte an.

Parameter für die Tests notieren

Natürlich müssen bestimmte Optionen von Komponente und Plugins verändert werden, dass alles abgedeckt wird, was im normalen Betrieb auftreten kann. Hier werden die Optionen erfasst, die für das Plugin von Bedeutung sind. Es wird überlegt, welche Einstellungen getestet werden müssen (zum Beispiel Pflichtangabe oder nicht). Das hängt nun tatsächlich auch wieder von der Testsituation ab. Teste ich das Plugin Buyer2Subscriber, dann ist es gleichgültig, was im der Komponente als Pflicht oder auch nur Anzeige von Vor- und Nachnamen eingestellt ist, denn Virtuemart liefert diese Daten immer, weil in Virtuemart ja eine Rechnung erstellt werden muss und diese Angaben dafür braucht. Teste ich allerdings das Plugin User2Subscriber, dann "ziehen" diese Einstellungen wohl! Hier sind die Test-Parameter also die entsprechenden Optionen der Komponente und der Plugins.

Es muss auch die Situation getestet werden, dass ein Abonnement für den Abonnenten vorhanden ist. Dieses vorhandene Abonnement kann natürlich auch wieder unterschiedliche Werte besitzen, die möglicherweise durch das Plugin geändert werden können, geändert werden dürfen oder eben nicht.

Alle Testfälle erfassen

Weiß man, von welcher Situation man ausgehen kann und was alles an Variationen möglich ist, kann man alle Testfälle erfassen. Sinnvollerweise gruppiert man die Tests erst mal so, dass immer nur ein Parameter verändert und alles andere beibehalten wird.

Auf der Hauptseite dieses Beitrags sind die Testfälle für das Plugin Buyer2Subscriber für BwPostman erfasst, hoffentlich bereits vollständig. Dies ist die Sortierung 1.

Sortieren der Tests nach Items

Die erste Sortierung ist ein Paradebeispiel dafür, wie DRY mit Füßen getreten wird.

Jetzt kann man sich überlegen, welche Testfälle zusammengefasst werden können, um DRY möglichst gut erfüllen zu können, ohne die Bedingung nur ein Item pro Test zu verletzen. Hierfür ist eine sinnvolle Definition nötig, was ein Item überhaupt ist.

Tests schreiben

Es bietet sich hier die Top-Down-Methode an, also auch wieder eine iterative Vorgehensweise ganz im Sinne der agilen Programmierung.

Das heißt, dass man erst mal eine leere Hülle für die Tests anlegt. Für jeden Test eine Methode, die nur den Namen und eine Beschreibung enthält. Es wird beschrieben, was getestet wird und welches Ergebnis erwartet wird. Dann werden die Tests in einzelne Schritte zerlegt. Diese Einzelschritte sind erst mal nur Aufrufe von Hilfsmethoden. Auf diese Weise bekommt man schnell ein Gespür dafür, was in einer Hilfsmethode erledigt werden kann, so dass sie bei mehreren Tests verwendet werden kann. Dieses Zerlegen in Einzelschritte kann immer weiter nach unten durch gereicht werden.

Hier kann man auch erkennen, ob die Sortierung und Gruppierung der Tests sinnvoll ist oder vielleicht noch mal überarbeitet werden muss.

Das mehrfache Verwenden von Hilfsmethoden kann so weit gehen, dass man die Hilfsmethoden in eigene Klassen auslagert, damit sie von anderen Testsuiten ebenfalls verwendet werden können. Im Beispiel gibt es die Hilfsmethode Bestehenden Abonnenten anlegen. (Ja, kling etwas komisch, dass man etwas anlegen muss, was schon besteht.) Diese Methode ist nicht nur im Plugin Buyer2Subscriber nützlich. Sie kann ebenfalls bei den Tests für das Plugin User2Subscriber, das Modul zur Anmeldung und selbst bei Komponente bei den Tests zur Anmeldung verwendet werden, denn in all diesen Situationen muss ja auch überprüft werden, wie sich "das System" verhält, wenn jemand ein Abonnement haben will, diese Mailadresse (die der Dreh- und Angelpunkt und der einzig verlässliche Indikator für einen Abonnenten in ganz BwPostman ist) BwPostman aber schon bekannt ist, also der potentielle/neue Abonnent bereits ein Abonnement hat.

Bei den Tests ist es eben wie im echten Programmierer-Leben: Gut durchdacht hilft es, DRY einzuhalten. Tests (genauer: automatische Tests) sind ja nichts anderes als Code, der geschrieben und ausgeführt wird. Manchmal macht es Sinn, manchmal sogar viel Sinn, seine Vorgehensweise so anzupassen oder abzuändern, dass man möglichst viel in einfache und leicht bedienbare Hilfsmethoden "auslagert".

Tests testen

Ja, auch das gehört dazu! Wie will man behaupten, dass die Tests verlässlich sind, wenn man sie nicht getestet hat?

Tests freigeben

Vielleicht ist das nur einfach einen Haken auf einer ToDo-Liste, vielleicht ist es ein Einpflegen in sein System für Continuous Delivery, ein Eintrag in Jenkins oder was auch immer. Jedenfalls ist das im Sinne von DevOps eine Auslieferung an den Kunden in diesem Fall ist der Kunde die Programmierung.