Unitils Test-Bibliothek

bin gerade bei der Recherche, wie man eine generische equals-Methode schreibt auf diese Bibliothek gestoßen, die mir genau das anbieten was ich selber schreiben wollte.

Unitils

Unitils is an open source library aimed at making unit and integration testing easy and maintainable.

Und dieses Feature brauche ich:

Reflection assert
[ul]
[li] Equality assertion through reflection
[/li]> [li] Possibility to ignore order of collections and Java default/null values
[/li]> [/ul]

Ich brauch das, weil ich ich generierte komplexe Datentypen habe, die alle keine equals-Methode implementieren. Mit diesen Datentypen hantiere ich auch in den Unit-Tests und will mich nicht mit ellenlangen Punkt-Konkatinationen rumärgern.

IMHO schreib dir custom asserts, alle mal besser als sich mit generischen Fehlermeldungen rumzuaergern.

Eine Frage oder so war da jetzt nicht dabei…?

Ein „Mittelding“ wäre ggf. noch EqualsBuilder (Apache Commons Lang 3.5 API) . Das macht aber keine „tiefen“ vergleiche.

Das Unitils könnte sinnvoll sein, aber … scheint schon eine Weile nicht weiterentwickelt worden zu sein, und den Code hab’ ich auf die Schnelle auch nicht gefunden.

Die spannende Frage bei sowas ist ja, wie es mit Sonderfällen umgeht: Collections, die sich selbst als Element enthalten, oder allgemein Zyklen in Objektgraphen. Das KANN man alles vermeintlich leicht behandeln: „Leg’ doch alle schon besuchten Objekte in ein ‚Set‘!“. Aber … wenn es gerade um Objekte geht, die kein vernünftiges hashCode/equals haben, denke ich, dass es da schon Stolpersteine geben kann.

Aber was soll’s: Ausprobieren, und wenn’s geht is’ gut :smiley:

Eine Frage nicht, wir sind hier ja in der Fundgrube und ich wollte euch an meinem Fund teilhaben lassen :wink:


In den Code hab ich reingeschaut beim debuggen, bin ich ja auch bisschen neugierig wie die das genau machen.

Für meine aktuellen Datentypen funktioniert es. Im provozierten Fehlerfall werden auch die gefundenen Unterschiede korrekt aufgeführt.

Auf den EqualsBuilder von Apache Commons war ich auch gestoßen, allerdings brauch ich schon tiefe Vergleiche. Diese generierten Datentypen sind einfach extrem verschachtelt.

Klasse A hat Feld vom Typ B, Klasse B hat Feld vom Typ C, Klasse C hat Feld vom Typ D usw. teilweise müsste ich mich durch 5 Klassen hangeln bis ich bei Java-Datentypen angekommen bin.

@maki
Was meinst du mit generischen Fehlermeldungen? Ich bekomme dort Meldungen wie diese:

--- Found following differences ---
[1].value.value[0].key: expected: "KeyA", actual: "Key1"

Und zusätzlich gibt es noch einen „Difference detail tree“, der alle Ebenen auflistet bis zum gefundenen Unterschied. Mir ist so eine Meldung aussagekräftig genug.