[ideas] Mockarro: an experiment on the injection of indirect inputs to a method under test

[marekdec]

It's been aeons ago when I came up with this here... (http://
groups.google.com/group/mockito/browse_frm/thread/943cd3606ee0cf8?
tvc=1#)

Anyways, I gave Mockarro another try recently and I manage to produce
a kind of a release candidate.
It's built upon the latest release of Mockito and it's still waiting
for a community evaluation.

the project webpage can be found at: http://code.google.com/p/mockarro/
a simple TDD with Mockarro example: http://marekdec.wordpress.com/2012/01/30/mockarro-tdd-example/

thanks for all feedback,
Marek

[David Wallace]

Hey Marek,
I think it's a fantastic idea. I didn't quite understand your idea
when you first raised it a few months ago in this group; but now that
I have grokked it fully, I think it deserves to go far. I can imagine
myself writing tests that use the isRequested feature; and I can
imagine persuading my boss that Mockarro is worth using on a project.

My one reservation about Mockarro is the name that you've chosen. I
assume that you chose the Spanish for (roughly) "big gob of snot", so
that it would contrast with Mockito (roughly "little gob of snot").
But it makes it more difficult for me to take your product seriously.
At least in the case of Mockito, I can accept the name as being an
unfortunate accident; to a native speaker of English with some
knowledge of Romance languages, it still sounds like "little thing for
mocking". But with Mockarro, the unfortunate connotations of the name
seem a whole lot less coincidental.

So if you want your product to be adopted by serious businesses
working on serious projects, I would strongly suggest a change of
name.

Good luck with Mockarro anyway, regardless of whether you follow my
advice.

Cheers,
David.

[Brice Dutheil]

Hi,

This is still a great idea.

As David I'm not really a fan of Mockarro as a name. But that might be a personnal preference.

And if possible you should release on central some alpa or incubating version this would simplify things for company that have their own Nexus server. 

On another topic do you use the injection mechanism of Mockito?

I was thinking about exposing a pluggable / configurable dependency resolver.

Regards,

-- 

Brice Dutheil

--

You received this message because you are subscribed to the Google Groups "mockito" group.

To post to this group, send email to moc...@googlegroups.com.

To unsubscribe from this group, send email to mockito+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/mockito?hl=en.

[Szczepan Faber]

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! 

--
You received this message because you are subscribed to the Google Groups "mockito" group.
To post to this group, send email to moc...@googlegroups.com.
To unsubscribe from this group, send email to mockito+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mockito?hl=en.

--
Szczepan Faber
Principal engineer@gradleware
Lead@mockito

[marekdec]

Hi,

@David
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
mind :)

@Brice
I'll promote some candidate version to Central this weekend, will keep
you posted.

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
good fit.

@Szczepan
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
related concerns).

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,
Marek

On Jan 30, 11:35 am, Szczepan Faber <szcze...@gmail.com> wrote:
> 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!
>

[Szczepan Faber]

Thanks for info! :)

[marekdec]

I've been thinking on a new name for Mockarro and came up with
following:
how do like "Komaar"? That'd be a Polish word for mosquito: +komar+
with a bit of noise to make it somehow unique.
It'd be something close to an anagram of "Mockarro", and quite
accidentally would relate to Mockarro's injection capabilities :)

What do you think?

[David Wallace]

I think Komaar is a superb name; but google translate tells me it's
Norwegian for coma. I don't know if that bothers you or not.

If you want it to be komar with extra noise, did you consider either
Komarr or Komarro? These are even closer to being anagrams of
Mockarro, and they feel really nice to say, if you use a really long
rolled R. I also don't know of any language in which either word
means anything, and more importantly neither does google translate.

Komarr is, however, the name of a planet in a series of science
fiction books - if you like Komarr, you might want to check with the
author whether she has any objection to you using it.

Cheers,
David.

> > > Marek- Hide quoted text -
>
> - Show quoted text -

[marekdec]

Hey David,

Thanks for your comments. I'll probably stay with Komarro.
See the current Mockarro home page for the logo proposal:
http://code.google.com/p/mockarro/

As this starts not to be Mockito related I created a new thread on the
Mockarro discussion group: http://groups.google.com/group/mockarro/browse_frm/thread/32bcc94d554c8908.
Please join the thread if you're interested.

rgds,
Marek

[Brice Dutheil]

About naming I'm thinking that your project is more about mocking whatever dependency is under the hood.

So I'm thinking "Mocking Whatever" => Evermock.

Just saying that as "Komaar" or other derivatives doesn't ring a bell in my french head ;)

-- 

Brice

[Clint Checketts]

Your logo could be a raven. http://www.heise.de/ix/raven/Literature/Lore/TheRaven.html 

(nevermore -> evermock)

[Brice Dutheil]

Ouch, my english level is insufficient to appreciate this poem as it should be. ;)

-- 

Brice

[Clint Checketts]

Maybe this will help:  http://dotsub.com/view/58591756-7128-488c-bfe9-22463d46d907 

[Brice Dutheil]

Yep it does a bit, thx :)

-- 

Brice

[Stupid Troll]

Here are some mock good ideas:

* MockyMock
* Promiscumock
* Who's On Mock?
* GloryMock
* So You Think You Can Mock
* Mocki Vanilli
* Mock Around The Clock
* For Those About to Mock
* Do you want to making mock...Berserker!
* GoMockYourself
* Mockey Mouse
* Mock mock mock, all day long, mock mock mock while I sing this song

[marekdec]

MockAndRoll?

[Brice Dutheil]

Hi I think there's plenty of interesting ideas.

Marek, I'm sure you can find a good name here ;)

mockandroll is pretty good imho!

-- 

Brice

MockAndRoll?

[Szczepan Faber]

Awesome ideas :D

[marekdec]

Thanks for your help and all the great ideas you posted here :)
In the end Mockarro has been renamed to Komarro, and released under
this name.

If you're interested in trying it out or following Komarro's future
development go to http://code.google.com/p/komarro/.

Thanks a lot,
Marek

On Feb 11, 5:37 pm, Szczepan Faber <szcze...@gmail.com> wrote:
> Awesome ideas :D
>

> On Tue, Feb 7, 2012 at 10:08 AM, Brice Dutheil <brice.duth...@gmail.com>wrote:
>
>
>
>
>
>
>
>
>
> > Hi I think there's plenty of interesting ideas.
>
> > Marek, I'm sure you can find a good name here ;)
> > mockandroll is pretty good imho!
>
> > --
> > Brice
>