quick JUnit question

[dexter195]

im trying to test to see if the contents of the acutal object are the same as the expected object but all i get is this

expected: <BankAccount@11b9fb1> but was: <BankAccount@913fe2>

both objects contain the same information but the assertEquals and the assertSame methods only seem to be checking to see if both objects are in the same memory location and not their values. ( please correct me if im wrong on this )

ive used other assertEquals methods on the data extrated from the two objects and they all pass.

are there any JUnit methods that will compare the info contained in the object (i havnt found any) or do i have to write individual test methods do achieve this?

thanks for your help

 

[Targol]

Tmho, the assertEquals method uses the equals method of the comparated objects to chack their equality. If you haven't overided the "public boolean equals(Object o)" method from Object class, your result is normal as this method return true only if comparated objects are the same (same instance with same id). In order for test to work, overide "equals" method in BankAccount object in order to return true if content is the same.

Water is not bad as long as it remains outside human body ;-)

 

[dexter195]

thanks targol

i was hopeing i wouldnt have to go down this alley. i presumed when you wanted to compare two objects in JUnit it would have taken for granted that one would be a mock object created for testing against an object created and manipulated by the various methods in the class.


at the moment im getting the results this way

assertTrue( baTest.getAccountBalance() == calc.getBankDetails().getAccountBalance() && baTest.getAccountNumber() == calc.getBankDetails().getAccountNumber()
                	&& baTest.getCustomerName() == calc.getBankDetails().getCustomerName() );

but i suppose if i was to override the equals method id have to create some sort of iterator that would iterate through the class and go through all the methods and compare the results from each object.

does anybody know where i should look for this kind of solution?

thanks again for the help

 

[Targol]

Just copy the code you used in assertTrue of Junit class inside the equals method of BankAccount like this :

public boolean equals(Object arg0) {
  if (arg0 instanceof BankAccount) {
     BankAccount ba = (BankAccount)arg0; 
     return (getAccountBalance() == ba.getAccountBalance()
          && getAccountNumber() == ba.getAccountNumber()
          && getCustomerName().equals(ba.getCustomerName()));            
  }
  return false;
}

Note that I uses "equals()" as comparator on the check on customerName unlike you did in assertTrue because I think there are mistakes here. You should have used "equals" method because, on Objects, "==" returns true if and only if the two sides of the comparator [red]are the same instance of the same object[/red]. "==" can only be used with basic types.

After equals override in BankAccount, change your assertTrue with :

assertTrue(baTest.equals(calc.getBankDetails()));

Hope that helps

Water is not bad as long as it remains outside human body ;-)

 

[dexter195]

cheers targol

that seems straight forward enough but is it at all possible to perfom that with objects that i havnt created or only have the class files for?

would my idea of iterating through the classes and getting the methods that return values and compairing those mean that, it would work for all objects or is this at all possible.

 

[Targol]

The way I gave you should work for any classes that overides "equals(method) from object (String class for example). For classes that don't override "equals", you can (even if you don't have the source) extend them in one of your own class that should only contain overriding of equals method (that's a possibility but that can be huge work if you work with many classes of that kind).

For the second question, I should answer 2 things :
[ul]
[li]calling all getters for the 2 classes to compare their results should be a little boring and should lead to tons of code.[/li]
[li]wether this kind of comparison is relevant or not is a business question depending on your classes business model.[/li]
[/ul]

Water is not bad as long as it remains outside human body ;-)

 

[timw]

Remember also that if you override the equals() method you generally need to override hashCode() too, since equal objects should return the same hashCode.

Tim
---------------------------
"Your morbid fear of losing,
destroys the lives you're using." - Ozzy

 

[Targol]

For what I know about it, HashCode method is used to optimise HashMaps. eg : Branches are created within the HashMap using Hashcode values to group near HashCodes value within the same branch. With this kind of sorting, methods such as "containsKey" start by searching nearest HashCode [red]before[/red] using equals method on objects. This behaviour impose to redefine both equals and hashCode methods. In Dexter case, I don't think you have to overide HashCode method while you don't store your objects into an HashMap... but I may be wrong... What do you think about it Tim ?

Water is not bad as long as it remains outside human body ;-)

 

[dexter195]

thanks lads.

your suggestion of overriding the equals method worked perfectly but it would only work with objects that i create myself.

i think i might just have to re-assess my methods and see if it's possible to simplify them so i dont need to check all the information contained in the object.

 

[timw]

Hi Targol. Since one of the strengths of OO is that objects could be re-used in new situations, I would tends to keep the equals/hashCode contract correct. You never know if your class will be used in a future situation which relies on this, and the problems an incorrect implementation could cause are likely to be subtle (I speak from experience since it's stung me before and only a well-placed JUnit test-case saved me from hours of hair-pulling ).

Tim
---------------------------
"Your morbid fear of losing,
destroys the lives you're using." - Ozzy

 

[Targol]

Hi Tim,
You're right on the principle but in almost all the cases that I've been confronted to, the default implementation of hashCode method worked well even if equals method was overriden. Don't know the computing made to claculate hashcode but in 90% cases, I didn't have to overide hashCode and that worked well with hashmaps....



Water is not bad as long as it remains outside human body ;-)

 

[timw]

tick ... tick ... tick ... boom!!

Tim
---------------------------
"Your morbid fear of losing,
destroys the lives you're using." - Ozzy

 

[Targol]

Life without danger is boring... and by the way, leaving few bugs in a program guarantees future work

Water is not bad as long as it remains outside human body ;-)

 

[timw]

Good point.

Tim
---------------------------
"Your morbid fear of losing,
destroys the lives you're using." - Ozzy