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
• 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. Da müssen auch alle "Rahmenbedingungen" der Programmteile erfasst werden, die für diese Testreihe nötig sind.
• 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.

Vorgehensweise

Die hier beschriebene Vorgehensweise ist vielleicht nicht das Nonplusultra, aber mir hilft es enorm.

Ausgangssituation der Tests bestimmen

Hier wird die Basis-Datenbestand der Testdaten definiert. 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).
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.

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.

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

Sortieren der Tests

Jetzt kann man sich überlegen, welche Testfälle zusammengefasst werden können.

Freilich hat man die Bedingung, dass pro Test nur ein Item getestet werden soll. Allerdings kann und sollte man mit Rücksicht auf DRY das Item eben selbst definieren.