Generieren von Testdaten für Komponententests für verschachtelte Objekte

8

Wenn ich mich über spöttische Dienste für Schreibgeräte-Testfälle für Java-Dienste auf Unternehmensebene lustig mache, finde ich die Einrichtung der Daten für die Unit-Testfälle sehr schmerzhaft. Meistens ist dies der einzig überzeugende Grund für Entwickler, Unit-Testfälle nicht zu schreiben und stattdessen Testfälle für den Integrationsstil zu schreiben. Wenn der Dienst von einigen anderen Diensten (die von ihren jeweiligen DAOs abhängen) und einem eigenen DAO abhängig ist, wird das Generieren der when-thenReturn -Klauseln für ein vernünftig verschachteltes Objekt ziemlich mühselig und Entwickler werden als der einfache Weg angesehen und Laden des gesamten Federkontexts und Quellen ihrer Daten von den direkten Quellen, die nicht immer die Daten ergeben, die alle erforderlichen Codepfade durchlaufen können. Vor diesem Hintergrund schlug ein Kollege von mir vor, einen Beispielintegrationstest durchzuführen und unter Verwendung von Aspekten alle relevanten Datenpunkte zu erfassen und zu einer XML-Darstellung zu serialisieren, die für die Materialisierung von Testdaten für den Komponententest verwendet werden kann Fälle. Zu unserer angenehmen Überraschung fanden wir einen Rahmen namens TestDataCaptureJ auf github , der diesem sehr ähnlich war. Es verwendete Aspekte, um die Datenpunkte zu erfassen, und es erzeugte den Java-Code, um die Objekte zu erstellen.

Die Motivation , die auf der Website angegeben wurde, schien sehr passend zu sein, und ich fragte mich, ob es andere Alternativen gibt kann ähnliche Merkmale geben. Es wäre auch großartig, wenn die Experten diesen Gesamtansatz kritisieren könnten.

Außerdem ist das Projekt ungefähr 2 Jahre alt und hat ein paar Käfer, die wir reparieren mussten und hoffen, es als eine mavenisierte Gittichgabel zurückzugeben. Nur um sicherzustellen, dass es keine andere ähnliche Initiative von einem der bekannten Ställe gibt.

Vielen Dank im Voraus!

    
Kilokahn 24.09.2012, 16:02
quelle

1 Antwort

8

Ich habe zwei Kritiken zu diesem Ansatz ... und bitte bedenken Sie, dass mein Wissen über Ihren Kontext fast null ist, was bedeutet, dass das, was ich hier vorschlage, bei Ihnen vielleicht nicht funktioniert.

Ich habe nur einmal ein Problem wie das von Ihnen erwähnte erlebt, und es war ein Symptom, dass es zwischen den Objekten zu viel Kopplung gab, weil die Verantwortlichkeiten weit waren. Seitdem verwende ich einen Domain-Driven Design Ansatz und ich hatte dieses Problem nicht mehr.

Ich bevorzuge es, Testdaten Builder zu verwenden, um Testdaten zu erstellen. Dieser Ansatz ermöglicht es mir, eine Vorlage von dem zu haben, was ich erstellen möchte, und ersetze nur die Bits, die mich interessieren. Wenn Sie sich für diesen Weg entscheiden, empfehlen wir Ihnen dringend, eine kleine Bibliothek namens Make-It-Easy vereinfacht die Erstellung dieser Builder.

Und zwei Vorschläge

Wenn Sie etwas Zeit haben, empfehle ich Ihnen

  1. Sehen Sie sich eine Voreinstellung namens Die tiefe Synergie zwischen Testbarkeit und gutem Design von Michael Feathers an - Teil des Vortrags handelt von etwas, das dem sehr ähnlich ist du erlebst.
  2. Lesen Sie das Buch Objektorientierte Systeme wachsen, von Tests geleitet (alias GOOS), es hat alle Arten von Einsichten darüber, wie man einfachen, erstaunlichen, testbaren Code schreibt.
Augusto 24.09.2012, 19:31
quelle

Tags und Links