J-Unit vergleich von 2 Objekten merkwürdig

[phraid]

Hallo zusammen,

folgender Hintergrund: Es existiert eine Methode die aus Datenbankinhalten ein Objekt erzeugt, welches einfach bestimmte Werte der Datenbank als Attribute enthält.
Eine weitere Instantz des gleichen Objekts mit den gleichen Werten wird von mir manuell erzeugt.
Beim Vergleichen der beiden Objekte mittels assertEquals(Object, Object) in JUnit bringt mir aber ein Fehler, nämlich:
"junit.framework.AssertionFailedError: expected:<de.tud.tk.packet.Entry@6acd5f8b> but was:<de.tud.tk.packet.Entry@513bd574>"

Ich habe sicherheitshalber alle Attribute des Objekts über Getter Methoden überprüft und die stimmen überein. Was kreidet JUnit mir hier an und wie könnte ich das Problem lösen?

mfG

 

[bygones]

haben die Objekte eine gueltige equals methode ? mehr macht junit nicht

 

[maki]

Anstatt equals/assertEuals kann man auch einen sog customAssert nutzen.

 

[ocoal]

Falls Du keine equals() Methode implementiert hast, solltest Du dies nachholen.

Die meisten größeren Entwicklungsumgebungen/IDE (wie z.B. Eclipse oder Netbeans) bieten Dir hierfür sogar kleine Helferfunktionen an.

Wenn Du dann schon dabei bist, equals() zu implementieren (bzw. zu überschreiben), dann kannst Du auch gleich hashCode() mit implementieren.

Hier noch ein kleines Tutorial mit Hintergrundinformationen zu den Vergleichsmethoden:

• equals() und hashCode() richtig überschreiben : blog.buhbuhbuh.de

-Colin-

 

[Wildcard]

Falls Du keine equals() Methode implementiert hast, solltest Du dies nachholen.

Warum? Wenn es der Produktiv Code nicht erfordert equals und hashcode zu überschreiben, dann würde ich es auch nicht tun. Macht die Sache dann nur langsamer.
Da es ja nur um den Test geht, reicht ein eigenes Assert.

 

[nillehammer]

Warum? Wenn es der Produktiv Code nicht erfordert equals und hashcode zu überschreiben, dann würde ich es auch nicht tun.

Bei Klassen mit Value-Semantik (wie z.B. welche, die in einer Datenbank gespeichert werden) sollten equals und hashCode immer überschrieben werden. Auch wenn man es aktuell selbst nie aufruft, spätestens, wenn Instanzen solcher Klassen in Sets landen solllen, braucht man es.

 

[maki]

Was Wilcard sagte war: Wenn es der Prod. Code nicht braucht, dann soll man es nicht nur für einen Test in den Prod. Code hinzufügen

Test Logic in Production at XUnitPatterns.com

Sicherlich, equals & hashcode braucht man häufig, aber eben nicht immer. Vor allem ist aber ein vergleich im Prod Code nicht immer genau das was ein Vergleich im Testcode ist, CustomAssertions sind flexibel und "verunreiningen" den Prod Code nicht.

Custom Assertion at XUnitPatterns.com

 

[bygones]

Was Wilcard sagte war: Wenn es der Prod. Code nicht braucht, dann soll man es nicht nur für einen Test in den Prod. Code hinzufügen

Test Logic in Production at XUnitPatterns.com

Sicherlich, equals & hashcode braucht man häufig, aber eben nicht immer. Vor allem ist aber ein vergleich im Prod Code nicht immer genau das was ein Vergleich im Testcode ist, CustomAssertions sind flexibel und "verunreiningen" den Prod Code nicht.

Custom Assertion at XUnitPatterns.com

auch wenn es sehr offtopic ist: UCDetector ist ein tolles eclipse tool um u.a. code aufzuspueren der nur von tests aufgerufen wird....

Bei Klassen mit Value-Semantik (wie z.B. welche, die in einer Datenbank gespeichert werden) sollten equals und hashCode immer überschrieben werden. Auch wenn man es aktuell selbst nie aufruft, spätestens, wenn Instanzen solcher Klassen in Sets landen solllen, braucht man es.

wie du selbst richtig sagst, "spaetestens, wenn". D.h. dann kannst du das noch hinzufuegen. Fuege NIE code hinzu der aktuell nicht gebraucht wird. Das Argument dass man es aber bestimmt wann anders mal brauchen wird ist nichtig.