(JUnit) Testdaten generieren - Framework?

[darekkay]

Ich komme langsam an den Punkt, wo ich komplexere Datenstrukturen mit JUnit testen möchte. Beispielsweise habe ich eine Methode, die eine Tree-Datenstruktur erzeugt. Nun möchte ich natürlich wissen, ob diese richtig funktioniert. Das "einfachste": per Hand einen Baum aufbauen, jedem Knoten Attribute vergeben und am Ende alle Fälle überprüfen (Kinder richtig zugeordnet, Anzahl aller Knoten, Attribute, ...).

Die Generierung des Testbaums sieht natürlich sehr unschön aus, dauert ewig und ist wahrscheinlich auch schwer wartbar. Was ich mir gut vorstellen könnte, wäre ein XML-Format:

<tree name="0" sortindex="0">
   <tree name="1" sortindex="1" />
   <tree name="2" sortindex="2">
      <tree name="12" sortindex="1" />
      <tree name="13" sortindex="2" />
   </tree>
</tree>

Man könnte jetzt einen eigenen XML-Parser bauen, versuchen die Attribute mit Reflections zu mappen, und und und. Da ich aber wahrscheinlich nicht der erste bin, der vor diesem Problem steht - gibt es hierfür ein fertiges Framework, das einem die Arbeit abnimmt oder erleichtert? Für Datenbank-Geschichten gibt es schließlich auch DBUnit, das einem erlaubt, Testtabellen im XML-Format zu erstellen.

 

[maki]

Hi darekkay,

kenne so ein spezielles Testframework nicht, gibt aber genug andere APIs um XML in Java in Objekte zu verwandeln (JAXB, EMF, etc. ), allerdings sind die sehr generisch und erfordern daher Anpassungsaufwand, ob es dann nicht wieder einfacher wird das in Java zu schreiben? 😉
Martin Fowler nennt dafür die ObjectMother, nix anderes als eine Factory für Testobjekte.
Die einzelnen Factory Methoden sollten dabei sehr sprechend sein (Anonymes Objekt vs. Objekt mit bekannten Daten, MockObject, etc. pp.).

Grundsätzlich sollte man vorsichtig sein wenn man bei Unittests XML Daten verwendet, macht die Tests schwerer zu verstehen und zu warten.
Integrationstests (zB. mit RDBMS) sind von Haus aus komplex und schwieriger zu warten als reine (isolierte) Unittests, also fragil 😉
Nebenbei bemerkt, selbst für DBUnit bietet es sich oft schon an - zB. bei Modul-Integrationstests - eine eigene kleine API zu schreiben (Ein isolierter Unitest braucht in der Regel viel weniger Testdaten als ein Integrationstest), wenn man Dinge zentralisiert (Konstruktoraufrufe zB.) und sauber hält (redundanzfrei, kurze Methoden, etc. pp.) hat man später weniger Stellen an denen man Änderungen machen muss.

 

[darekkay]

Vielen Dank für die ausführliche Antwort! 🙂

Das Stichwort "ObjectMother" hat mich auf das Builder-Pattern gebracht, das richtig schick aussieht:
Mistaeks I Hav Made: Test Data Builders: an alternative to the Object Mother pattern

Das sollte ein gutes Mittelmaß zwischen Übersichtlichkeit, Aufwand und Wartbarkeit bilden.