loose2200 / mockito

Automatically exported from code.google.com/p/mockito
0 stars 0 forks source link

Equality of Empty Arrays #487

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Create an empty array array1 of type S (anything - for example Integer)
2. Create another empty array array2 of type T (anything other than S - for 
example Long)
3. areEquals(array1,array2)

What is the expected output? What do you see instead?
I expect not equals.  I see equals.

What version of the product are you using? On what operating system?

Please provide any additional information below.

Original issue reported on code.google.com by Emory.Me...@gmail.com on 14 Apr 2014 at 2:11

GoogleCodeExporter commented 8 years ago
I disagree with some of the tests in EqualityTest.java.

In particular
assertTrue(areEqual(new int[] {1}, new Integer[] {1}));
assertTrue(areEqual(new Object[] {"1"}, new String[] {"1"}));

because the compiler treats them as not equal.

Original comment by Emory.Me...@gmail.com on 14 Apr 2014 at 12:05

Attachments:

GoogleCodeExporter commented 8 years ago
Hey,

Thanks for the report! Why are you keen on making those changes? E.g. do you 
have a use case from a real project or you are in pursue of correctness of the 
model?

I'm not very keen on making those changes unless there is a good story behind 
it. To me new Integer(1) is the same as (int) 1 and I like the boxing/unboxing 
to get out of my way when writing code / testing. It feels like the current 
(lenient) behavior is more user friendly.

If that's ok, I'll close this ticket unless you have good use case to back up 
those changes :)

Original comment by szcze...@gmail.com on 20 Apr 2014 at 1:54

GoogleCodeExporter commented 8 years ago
Hello,

I support your decision to close this ticket.

I have a use case, but I realize that this change would break some existing 
tests and so I understand your reluctance.  Upon thinking about how I worked 
around this, I have a better solution that would solve my use case and not 
break any existing tests.  When I have some time I will write up a new ticket.

USE CASE
I created a method with a signature
abstract < T > T [ ] copyOfRange ( final T [ ] array , final Integer floor , 
final Integer ceiling )

Then in some other code, I call this copyOfRange method multiple times with the 
same floor and ceiling but different arrays.  

In my testing code, I lazily create mocks for the different arrays like
Object[]objects=new Object[]{}; String[]strings=new String[]{};
Object[]newObjects=new Object[]{}; String[]newStrings=new String[]{};
and specify the returns like
doReturn(newStrings).when(test).copyOfRange(strings,floor,ceiling);
doReturn(newObjects).when(test).copyOfRange(objects,floor,ceiling);

However, the test errors because during execution when it tries to do
copyOfRange(strings,floor,ceiling) mockito will return newObjects which is not 
the right type

Original comment by Emory.Me...@gmail.com on 20 Apr 2014 at 3:24

GoogleCodeExporter commented 8 years ago
Ok, thanks!

Original comment by szcze...@gmail.com on 20 Apr 2014 at 8:15