You're right, the name is not very fortunate. I'll try to rename soon
(I was planning to migrate the code to a git repo as apparently google-
code started hosting git repositories recently).
It looks I'll have to abandon the idea of a greenish logo I have in
I'll promote some candidate version to Central this weekend, will keep
I created a custom injection engine, which is actually an incidental
by-product of the whole thing. I guess that reusing the Mockito
injection engine would definitely be good for the size and complexity
of the codebase. I will have another look at this to see if it makes a
1. Mockarro with some Mockito help will have to be used. A Mockito
mock will have to be created and then passed to the Mockarro
instanceForTesting method (which would take care of all the injection
The fixture section (i.e. the given section) would use a plain
Mockarro aproach. The verification section however, would get an
explicit Mockito.verify statement. This way we can get rid of the
implicit verification that happens to be performed when using the
Mockito.when idiom in the //when part of the test (even though the
verification does not belong there).
2. The basic idea of Mockarro is to hide the notion of the stubbed
type(s). When defining the indirect inputs, it should be only
important to specify what is to be returned and not who/what returns
it. So if a method uses just one of those methods then we are good.
Still, you have a point here. What happens if the method-under-test
employs both collaborator's methods? Maybe a sequence of chained
thenReturn(anObject).thenReturn(anotherObject) would do.
(this, in any case, is not implemented yet). Or maybe leaving it as it
is to enforce some more specialised design would be a good idea...
Anyhow, as Mockarro is complemented with Mockito, the latter could
always be used as a last resort.
Thanks guys for all the feedback, it really helps,
On Jan 30, 11:35 am, Szczepan Faber <szcze...@gmail.com
> It's an interesting idea :). What's your take on 2 use cases:
> 1. The test author is interested in argument passed onto the collaborator
> (for example: the argument is calculated in the SUT or there are 2 similar
> interactions and one wants to be sure which one is stubbed).
> 2. The stubbed type has multiple methods returning the same type.
> Good luck!