11

I'm trying to get the hang of Java. Unit testing is pretty important to me and so recently I've started to use JUnit. It was tough to begin with but I'm getting the hang of it. All of my tests have worked up to this point, with the exception of comparing two objects of the same class (I haven't tried testing a function that creates an object of a different class). Basically, when I have a method within a class that creates a new instance of the class, and I try to test the method, I get a weird error.

"expected:runnersLog.MTLog@433c675d but was runnersLog.MTLog@3f91beef"

I have tried researching this problem, but haven't found anything of much help. Here's the link to my classes on github. The method I am trying to test is the mt() method, and the test class is ILogTest.

This is not the only case where I am having this problem. With any class that has a method that returns a new object of the same class, I am getting this exact same 3f91beef error (even when the object is more complicated - with arguments)

Sotirios Delimanolis
  • 274,122
  • 60
  • 696
  • 724

3 Answers3

13

assertEquals will use Object#equals for each object being compared. Looks like your class ILogTest doesn't override equals method, so calling Object#equals will just compare the references by itself, and since they're different object references, the result will be false.

You have two options:

  1. Override public boolean equals(Object o) in ILogTest.
  2. Use assertEquals on the relevant fields that implement equals method e.g. String, Integer, Long, etc. This one requires more code but is useful when you cannot modify the class(es) being asserted.
Luiggi Mendoza
  • 85,076
  • 16
  • 154
  • 332
  • Thanks, I'm not sure why this question is getting negative attention but you put it very plainly for me - cheers –  Jun 24 '15 at 17:09
  • When the equals() is overidden, how does the test's code change? –  Jun 24 '15 at 17:32
  • If you override `equals` method properly, then you won't have to change anything in your unit test (this is assuming that equals is properly implemented). – Luiggi Mendoza Jun 24 '15 at 17:33
2

You need to overrride equals, the equals method in the superclass Object checks for references if both references point to the same object equals is true if not false, so you need to write down an equals method that will check your objects content and check if the values are the same, it is also recommended that you override your hashCode method too.

An example could be:

Custom a= new Custom("");
Custom b= a;

//b would be equal a. because they reference the same object.
Custom c= new Custom("");
//c would not be equal to a, although the value is the same.

to learn more you could check: Why do I need to override the equals and hashCode methods in Java?

Community
  • 1
  • 1
DguezTorresEmmanuel
  • 348
  • 5
  • 10
1

If you are using a modern IDE for development (like Eclipse, IntelliJ etc), they can generate these methods for you. Check that out for two reasons: 1) to save time 2) To prevent possible bugs.

In eclipse IDE, you can do so by selecting source -> generate hashCode() and equals().

One more thing, when you implement of of these two, you have to implement the other one as well.

Alp
  • 3,027
  • 1
  • 13
  • 28
  • So when you generate these new methods, do they require any addition attention? –  Jun 24 '15 at 17:14
  • You don't have to override (not implement) both methods. It's a recommendation to do it, but it's not necessary. – Luiggi Mendoza Jun 24 '15 at 17:18
  • @Luiggi, if you are overriding them for sportive purposes, yes, you do not need to override them both. But in reality, you override them because there is a reason for that and that reason does NOT find an answer in the default implementation. So, it is both recommended and a very good idea to write them both. Don't take my word but [check this out](http://www.javapractices.com/topic/TopicAction.do?Id=17) – Alp Jun 24 '15 at 18:16
  • @David please take a look at [this link](http://www.javapractices.com/topic/TopicAction.do?Id=17) for how to write these methods. If you happen to have a copy of [Effective java](http://www.amazon.com/Effective-Java-Edition-Joshua-Bloch/dp/0321356683) consult there too. It is a great read. – Alp Jun 24 '15 at 18:18
  • I know that, but sometimes the best solution is: just don't. – Luiggi Mendoza Jun 24 '15 at 18:27
  • Don't fix if it ain't broken. So do NOT write equals (and hashcode along with it) if you do not really need it. But if you do, then make sure to write them both. I am done. – Alp Jun 24 '15 at 19:57