Diskussion:Buyer2Subscriber Tests

Gruppierung und Sortierung der Tests

Die Sortierung der Tests nach der Version 1 hilft für das genauere Planen und Entwickeln der einzelnen Tests nicht viel. Der erste Teil mit den Tests zur Installation, zum Update und zum Staus der Erweiterungen ist genauso wie die Tests zu den Optionen bereits ganz brauchbar.

Die Tests zur Funktionalität allerdings sind in dieser Sortierung und Reihenfolge nur nützlich um festzustellen, ob ich alle Tests erfasst habe. Um die Tests auch DRY-tauglich zu machen, nützt es nichts. Dafür kommt nun die zweite Sortierung.

Der grundsätzliche Ablauf der Tests wird so sein:

1. Aufruf der Produktseite
2. Produkt in den Warenkorb
3. sicherstellen, dass es auch im Warenkorb ist
4. auf die Seite für die Eingabe der Adressdaten wechseln
5. Eingaben je nach Testfall
6. Ergebnis kontrollieren
7. aufräumen

Die Schritte 1-4 sind immer dieselben. Schritt 7 hat kleinere Modifikationen, denn es gibt Tests, da muss ich nur die Bestellung aufräumen und solche, wo auch der Abonnent archiviert und gelöscht werden muss.

Schritt 5 ist der Schritt, der die eigentlichen Funktionstests zu diesem Plugin aus macht. Davon hängt dann ab, was ich zu kontrollieren habe. Also sollte ich diese beiden Schritte noch genauer zerlegen.

Schritt 5: Eingaben je nach Testfall

Überlegung 1

Der Unterschied zwischen den Tests, wo ich noch kein Abonnement habe zu denen, wo bereits ein Abonnement besteht, ist so groß, dass es dafür getrennte Tests oder Testgruppen geben wird.

Überlegung 2

Parameter, die sich nicht gegenseitig beeinflussen, können zusammengefasst werden. Allerdings muss sichergestellt sein, dass eine Änderung nicht eine andere beeinflusst. Wenn man im Hinterkopf behält, dass es eventuell doch Wechselwirkungen geben kann, dann kann man so was erst mal ausklammern und bei Bedarf nachreichen.

So ist es durchaus möglich, gleiche Werte bei den Adressdaten (Eingaben des Käufers in die Felder) und Mailingliste des neuen Abonnements zu einem bereits bestehenden Abonnement in einem Test zu realisieren.Grundsätzlich brauche ich ja sowieso Eingabedaten (dazu zählen allerdings auch leere Werte) in allen Feldern. Wenn diese Felder als Pflicht markiert sind, dann dürfen diese Eingabedaten nicht einmal leer sein.

Es ist zu überlegen, ob die Änderung an allen Adressdaten und der Mailingliste gegenüber einem vorhandenen Abonnement ebenfalls in einem Test realisiert werden. Hier bin ich noch unsicher. Grundsätzlich spricht nichts dagegen, auch das in einem oder einigen wenigen Tests zusammenzufassen. Ob ein oder mehrere Tests hängt von der Anzahl der Varianten/Eingabemöglichkeiten ab.

Folgerung 1

Ich habe 17 Testfälle identifiziert, die alle in die Kategorie Käufer hat noch kein Abo fallen. Die meisten Varianten liegen beim Format des Newsletters vor, es sind derer 6. Also kann ich mit maximal 6 Tests alle 17 Testfälle abdecken, ohne etwas aus zu lassen.

Des weiteren habe ich 32 Testfälle identifiziert, die in die Kategorie Käufer hat bereits ein Abo fallen. Die meisten Varianten liegen hier bei der Auswahl des Geschlechts vor, denn es gibt ja drei Möglichkeiten. Also drei Angaben für das vorhandene Abonnement kombiniert mit drei möglichen Eingaben, dazu noch die Möglichkeit, dass der Wert gar nicht (neu) erfasst werden soll. Ergibt maximal 12 Kombinationen. Also müsste ich auch mit maximal 12 Tests auskommen, wenn ich als gegeben ansehe, dass sich die Parameter nicht gegenseitig beeinflussen.

Für die 49 Testfälle, die hier untersucht werden, brauche ich also maximal 18 Tests. Das ist schon eine erhebliche Reduzierung, aber vielleicht geht noch mehr?

Ich kann nur an den Parametern ansetzen, die die meisten Testfälle haben…

Eine Hürde, die Tests weiter zusammen zu fassen, liegt darin, dass ich ja nicht auf einem Screen bleiben und mehrere Werte ausprobieren kann, denn um das Ergebnis bei den Abonnenten zu sehen, muss ich die Bestellung abschicken. Eine Ausnahme aber gibt es: Die Tests, die auf leere Eingaben bei Pflichtfeldern prüfen. Da komme ich mit der Bestellung, ja nicht mal mit dem Speichern der Adressdaten weiter, solange die Felder leer bleiben. Da dies aber nur beim zusätzlichen Feld der Fall ist und hier sowieso nur jeweils 6 Testfälle vorhanden sind, hat das keine Auswirkung.

Folglich komme ich hier wohl nicht unter die 18 Tests.

Eingabe- und Ergebnisdaten

Die Eingabedaten kann ich in einem indizierten (Schlüssel ist eine Nummer) Array zusammenfassen, das ein assoziatives (Schüssel ist ein Name/String) Array pro Testfall enthält. Damit kann ich die gleiche Datenstruktur auch für die erwarteten Ergebnisse verwenden.

Sicherer wäre es allerdings, wenn ich den Testfällen Namen und damit aus den Nummern des äußeren Arrays ebenfalls Strings machen könnte. Dann wäre es auch möglich, die Eingabedaten und die Ergebnisdaten in einer anderen Reihenfolge vor zu halten. Die Herausforderung hier besteht darin, dass sprechende Namen gefunden werden müssen, die allerdings nicht zu lang sein sollten.

Für die Tests, die auf kein Abonnement prüfen sollen, kann ich immer dieselben Daten nehmen. Da wäre einer der Datensätze möglich, die ich für ein neues Abonnement verwende, warum also nicht gleich der erste? Das spart mehrfach gleiche Daten.

Es ist zu überlegen, ob ich die variablen Daten nicht auch als Array in einem Array anlege. Aber das macht die ganze Sache ziemlich unübersichtlich…

Schritt 6: Überprüfung der Ergebnisse

Bei den Testfällen und beim Gerüst für die einzelnen Tests habe ich schon notiert, was für ein Ergebnis ich jeweils erwarte. Durch geschickte Bestückung des Arrays für die Ergebnisse und Setzen der Eigenschaften der Testklasse kann ich die Prüfung in einer einzigen Hilfsmethode durchführen. Da ich hier grundsätzlich zwei verschiedene Ergebnisbereiche abdecken muss, macht es allerdings wenig Sinn, wenn die Arrays geschickt bestückt sind. Da kann ich auch eine Ergebnisprüfung für kein Abonnement und eine für Abonnement anlegen. Die Prüfung für Abonnement kann sowohl die Tests für neues Abonnement als auch die Tests für bereits vorhandenes Abonnement abdecken. Die zu prüfenden Einzelwerte sind ja immer dieselben.

Es ist noch zu überlegen, ob neues Abonnement und vorhandenes Abonnement möglicherweise getrennte Arrays bekommt, damit ich nicht zu viele gleiche Einzel-Arrays anlegen muss.

Eigenschaften der Testklasse

Die Eigenschaften der Testklasse werden vornehmlich dazu verwendet, die Anzahl der Übergabe-Parameter an die Hilfsmethoden so gering wie möglich zu halten. So könnte ich auch die Prüfung der Ergebnisse für die Tests, die kein Abonnement bewirken, in die Methode zur Überprüfung der Ergebnisse integrieren. Oder ich lege eine generelle Methode Überprüfung der Testergebnisse an, wo ich dann anhand der entsprechenden Eigenschaft auf eine weitere Hilfsmethode weiterleite. Schalter an, Methode 1, Schalter aus Methode 2.  Viel Sinn macht es nicht, denn es erhöht die Lesbarkeit des Codes nicht wirklich.

In anderen Fällen macht es durchaus Sinn, Eigenschaften der Testklasse statt Parameter als Transporteur zu verwenden.