Hallo,

ich setze gerade eine Regelprüfung für ein Vertragswerk um, vereinfacht gesagt ist das eine Eingabeprüfung auf Kombinationen, d.h. gebe ich am Tag X den Wert A ein, darf ich an dem Tag kein B, C und D eingeben aber ein E.
Da ich in das Tagesgeschäft mehr mit Unittests machen will, prüfe ich das ganze darüber ab.


Nun gibt es in diesem großen Vertragswerk mehrere Unterverträge, die alle recht identisch sind. Wäre alles gleich, würde eine Klasse für die Regelprüfung reichen, aber es gibt halt kleine Abweichungen:

Vertrag 1: gebe ich am Tag X den Wert A ein, darf ich an dem Tag kein B, C und D eingeben aber ein E.
Vertrag 2: gebe ich am Tag X den Wert A ein, darf ich an dem Tag kein B, C, D und E eingeben.
Vertrag 3: wie Vertrag 1
Vertrag 4: wie Vertrag 1
Vertrag 5: wie Vertrag 2
Vertrag 6: nochmal anders


für die Regelprüfung kann ich das ja recht gut zusammen fassen und per Vererbung von einer Basisklasse gleiche Prüfungen ableiten und kleine Unterschiede in der Kindklasse ändern.

Nur was ist mit den Unittests für die einzelnen Unterverträge? Wenn ich für jeden Untervertrag alle Prüfungen in eine eigene Testklasse packe, dann gibt das jede Menge copy-Paste-Code. Oder geht man in dem Fall auch her und baut sich eine abstrakte Basis-Testklasse und ruft dann in den abgeleiteten Testklassen für die Unterverträge nur noch die entsprechenden Regelprüfungen auf?

Oder denke ich hier viel zu "konkret" und müsste hier abstrakter vorgehen?

Ja, eine Basisklasse für Tests (die nicht abstrakt sein muss) von der andere Testklassen abgeleitet sind ist ein Weg Copy/Paste zu vermeiden. Im Standardwerk "xUnit Test Patterns" wird dies "Testcase Superclass" genannt. Voraussetzung dafür ist dass die benötigten fachlichen Klassen alle von der Testcase Superclass aus "sichtbar" sind. Es gibt einige verwandte Patterns die alle darauf abzielen in den Tests "Test Helper" zu benutzen in denen wiederverwertbarer Code enthalten ist. Anstatt in einer Superklasse können Test Helper Methoden auch in einer separaten Klasse gesammelt werden - von der dann im Test (z.B. im Setup) eine Instanz erzeugt wird.

Achtung! Bei Verwendung dieses Patterns unbedingt darauf achten, ob die zu testenden Units auch strukturell identisch sind. Es kann auch sein, das dies eine willkürliche Entscheidung ist, die sich jederzeit ändern kann.

Wenn dem so ist, und man voneinander abgeleitete Testklassen hat, rennt man gegen die Wand, wenn sich in den Verträgen das Verwandschaftsverhältnis ändert.

Daher sind Testhelper eher geeignet, die 'zufällige' Gemeinsamkeit im Test mit DRY abzubilden.