Can't tell the difference between one mock and another

[GoogleCodeExporter]

My mocks just toString() to "Mock for <class>".

Can I optionally construct them with a name, so I get, say

"Mock <name> for <class>"

so that I can tell the difference between two mocks for the same class, please?

(This is of course only applicable if I'm not mocking toString()... )

Original issue reported on code.google.com by featheredwings@gmail.com on 13 Mar 2008 at 4:32

[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 iczechowski@gmail.com 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 szcze...@gmail.com 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 szcze...@gmail.com 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 szcze...@gmail.com 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 featheredwings@gmail.com 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 featheredwings@gmail.com 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 szcze...@gmail.com on 22 Mar 2008 at 6:44

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 19 Apr 2009 at 7:40

• Added labels: Milestone-Pre1.7