jUnit und Test von equals, hashCode, toString

[fastjack]

Hallo,

ich wollte mal fragen, wie ihr die von Object-überladenden Methoden hashCode(), equals() und toString() vernünftig in jUnit testet. toString() ist ja noch relativ harmlos, aber equals und hashCode bei Objekten mit mehreren Attributen hat es glaube ich sehr in sich, wenn man wirklich komplett (nach Coverage) testen will. Vielleicht bin ich auch auf dem Holzweg ...

Danke.

 

[@x.l]

Ich mach mir eigentlich nicht die Mühe equals und hashCode zu testen, da ich mir diese von der IDE erzeugen lasse und darauf vertraue, dass es funktioniert.

 

[fastjack]

Danke @x.l. Ich verlasse mich allerdings nur ungern auf die IDE und zumal ich dann die Methoden aus der Coverage nehmen müßte. Ich habe jetzt einige assert-Metoden geschrieben, die das machen, was ich möchte (denke ich 😉 ).

http://www.java-forum.org/blogs/fastjack/127-testen-equals-hashcode.html

 

[FArt]

Nach welchen Kriterien sollen diese Methoden denn getestet werden?
equals geht ja noch, aber sonst....

 

[mvitz]

equals geht und hashcode kann man dann insofern testen, dass bei Objekten für die equals == true gilt, auch hashCode == hashCode ist.

 

[FArt]

equals geht und hashcode kann man dann insofern testen, dass bei Objekten für die equals == true gilt, auch hashCode == hashCode ist.

Und mit welchem Effekt?
Wenn ein Objekt x Attribute für equals und hashCode heranzieht und y Attribute nicht, wie viele verschiedene Objekte (mit variierenden Attributen alle Kombinationen) muss ich dann im Test erzeugen und überprüfen um das wirklich validieren zu können? Und was habe ich mit diesem Aufwand dann gewonnen?

Ich bin ja auch für Unittests, aber man sollte doch die Kirche im Dorf lassen und nicht päpstlicher sein als der Papst.

 

[mvitz]

Hab ja nicht gesagt, dass es Sinnvoll ist 😉 Denke bei Objekten mit wenig Attributen, oder wo es Spezialfälle gibt könnte das ganze Sinnvoll sein.

Ansonsten kann man sich entweder auf die Generierung durch die IDE verlassen, oder eine Bibliothek wie z.B. commons-lang benutzen.

 

[bygones]

equals geht und hashcode kann man dann insofern testen, dass bei Objekten für die equals == true gilt, auch hashCode == hashCode ist.

halte ich für fragwürdig zu testen ... toString so und so... warum will man die String reprästenation eines objektes testen ?
hashcode

public int hashCode {
   return 42;
}

ist eine valide hashcode funktion - und zeigt die Fragwürdigkeit eines Testes.

bei equals fällt mir grad kein gegenbeispiel ein, aber auch hier würde ich nicht junit tests schreiben.

Dir scheint es um die Coverage zu gehen... pur auf diese Zahl zu achten ist unsinnig. Eine Coverage von 100% klingt für jeden Projektleiter / Kunden super, sagt aber nix aus, ob die Tests auch sinnvoll sind. Es zeigt mehr dass auch alle setter und getter getestet werden, was ebenso unsinnig ist...

 

[fastjack]

@all Danke für Eure Meinungen.

Ich finde die Korrektheit der equals() und hashCode() Methoden schon sehr wichtig, da sie in der Collection-API an allen Ecken und Enden verwendet werden. Ich erzeuge diese Methoden auch mit einer IDE (das bedeutet aber nicht, das ich Ihr 100%ig vertraue). Nur gab es in letzter Zeit häufiger das Problem, das Entwickler die Methoden, vorsichtig gesagt "verbessert" hatten, und ohne es zu Wissen den Equals-Kontrakt der Java-API (nachzulesen bei Object) verletzt hatten. Bis Fehler im Produktionssystem, die daraus entstanden sind gefunden wurden, sind Wochen vergangen. Beim Testen von toString() bin ich mir noch nicht so ganz sicher.

@vitz hat Recht, ein Punkt ist u.a. x.equals(y)==true dann muß hashCode(x) == hashCode(y) sein

@Fart ich dachte es gäbe eine Möglichkeit, den Aufwand gering zu halten. Aufgrund des obigen Fehlers denke ich aber heute, das er sich trotzdem lohnt.

@bygones dein hashCode ist natürlich völlig korrekt. der Kontrakt sagt ja auch nur was vitz erwähnte. Mit der Coverage gebe ich Dir recht, man kann auch Tests schreiben, die jede Codezeile covern aber überhaupt nichts testen 😉 Trotzdem denke ich, es nutzt, wenn es im Betrieb viele Entwickler gibt, die ständig irgendwo rumfummeln. Getter und Setter zu testen halte ich auch für unsinnig, da sie im Normalfall in anderen Testmethode der Klasse sowieso benutzt werden.

Schönen Feierband an Alle.

 

[FArt]

Ich erzeuge diese Methoden auch mit einer IDE (das bedeutet aber nicht, das ich Ihr 100%ig vertraue). Nur gab es in letzter Zeit häufiger das Problem, das Entwickler die Methoden, vorsichtig gesagt "verbessert" hatten, und ohne es zu Wissen den Equals-Kontrakt der Java-API (nachzulesen bei Object) verletzt hatten.

Wieso soll man ihr nicht vertrauen? Man sieht sich einmal an, wie diese generiert wird, bewertet das und fertig. Und natürlich ist es in der Verantwortung des Entwicklers die passenden Attribute auszuwählen. Und für die, die nicht wissen was sie tun, gibt es immer noch Codereviews.

 

[fastjack]

In Sachen IDE und Autogenerierungen habe ich eine gesunde Portion Skepsis. Es ist hilfereich, ohne Zweifel, allerdings entartet das auch meistens schnell in "blindem" Generieren. Solange bis jemand auf die Idee kommt die Templates zu "verbessern", was durchaus auch durch IDE Update passieren könnte.

Und für die, die nicht wissen was sie tun, gibt es immer noch Codereviews.

Wenn das mal in allen Firmen so wäre... Ich war in vielen kleinen Firmen, bei denen das schon meistens aus Kostengründen nicht Gang und Gebe war und dann hilft halt nur eins: Vertrauen ist gut, Kontrolle(Test) ist besser.

 

[bygones]

Wenn das mal in allen Firmen so wäre... Ich war in vielen kleinen Firmen, bei denen das schon meistens aus Kostengründen nicht Gang und Gebe war und dann hilft halt nur eins: Vertrauen ist gut, Kontrolle(Test) ist besser.

solange es in den Köpfen der Entscheider liegt dass Reviews und QS Verschwendung von Resourcen sind wirst du auch nicht bzgl testen weiter kommen. Warum sollte man Testen akzeptieren, aber Reviews als Verschwendung sehen ?
Mich wunderts immer wieder wie verbohrte Firmen es immer noch nicht gibt, die wirklich meinen diese Prozesse sind unsinn