Can't tell the difference between one mock and another about mockito

[GoogleCodeExporter]

Can you, please, provide an example where you have a need to distinguish two or 
more
mocks of the same class ?

Original comment by [email protected] on 13 Mar 2008 at 10:51

[GoogleCodeExporter]

An example would be great.

Frankly speaking, I deliberately removed naming mocks. I felt that naming mocks 
is
just a trick to deodorize a smell of big test with too many mocks...

Original comment by [email protected] on 14 Mar 2008 at 2:05

[GoogleCodeExporter]

Consider following code:

//mockOne and mockTwo are of the same class

verify(mockOne).doIt();
veriyf(mockTwo).doIt();

Why do you need names for those mocks? Stack trace will show you line of code 
where
verification fails - you will know which interaction/mock failed - just click on
first stack trace element...

Original comment by [email protected] on 16 Mar 2008 at 2:21

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Closing to clear backlog. 

Please look at our comments, tell us what you think and reopen if you feel like.

Original comment by [email protected] on 16 Mar 2008 at 2:27

• Changed state: WontFix

[GoogleCodeExporter]

I had this problem:

ParkingLot fullLot = mock(ParkingLot.class);
ParkingLot almostFullLot = mock(ParkingLot.class);
ParkingLot emptyLot = mock(ParkingLot.class);
Attendant attendant = new Attendant(lot1, lot2, lot3);
//... Make some lots full and some not, make some rule by which the attendants 
park
attendant.park();

verify(lot3).park();

So, it fails. I can verify that it fails. I can put a break point in the for... 
loop,
inside the attendant... but because there's just a set of parking lots, I can't 
see
which parking lot the attendant's observing / responding to at any time.

It turned out to be a stupid > instead of < - I had to use something other than
Mockito to spot the silly mistake, because I couldn't tell which parking lot 
was which.

So, yes, stack traces are fantastic. Names would be helpful when debugging, 
even if I
remove them once I've fixed the problem!

Original comment by [email protected] on 22 Mar 2008 at 1:11

[GoogleCodeExporter]

Even just making the mock debug as "Mock of Parking Lot@233725253", with the 
mock
object's ID, would do the trick; I can catch that in both the test and the 
attendant
and see which is which.

Of course, I could always try stubbing toString()... :P

Original comment by [email protected] on 22 Mar 2008 at 1:34

[GoogleCodeExporter]

OK, I can see that for debugging purposes it would be nice to name mocks.

For now mocks print hashCode value in toString(). Something like that:

"Mock for SomeClass, hashCode: 4323423"

The change is in trunk and will go out with the next release.

Please keep us posted if you come across problems that require explicitly 
naming mocks.

Original comment by [email protected] on 22 Mar 2008 at 6:44

[GoogleCodeExporter]

Original comment by [email protected] on 19 Apr 2009 at 7:40

• Added labels: Milestone-Pre1.7