[ideas] Future of mocking

[marekdec]

Hey guys,
dunno really if there's any better place to post this kind of things
(does sth like mockito-dev exist?), anyhow, recently I've been
thinking on mocking and unit testing in general and I came up with
some ideas. My thoughts where inspired by Mockito and maybe what I
produced could be of some help in the future.
Checkout my Mockarro experiment at http://code.google.com/p/mockarro/.
Thanks for all your comments and opinions.

[Szczepan Faber]

Hey,

It is a very cool idea. What if the inputs are less 'modelled', like
Strings for example?

Cheers,
Szczepan

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

[Johan Haleby]

Hi, 

I also think the idea is very interesting. I'll have to experiment with it a bit myself in order to get a feel for it though.

/Johan

[Szczepan Faber]

Exactly.

Another question is what to do you do when request to collaborator needs formal parameters.

Good stuff
Szczepan

03-05-2011 09:03 użytkownik "Johan Haleby" <johan....@gmail.com> napisał:

[Brice Dutheil]

Hi,

This is very cool, I like the idea.

The only point dislike a bit is having dependency on CDI or seam, etc, not every project needs such dependencies.

Also, did you check out the trunk, mockito has now constructor dependency injection mechanism. However this is still based on having mocks declared in the test.

Anyway this is a very nice experiment :)

-- 

Bryce

2011/5/3 Szczepan Faber <szcz...@gmail.com>

[marekdec]

@Bryce
In terms of maven the dependencies are optional i.e. the project does
not depend on any DI framework. Also in no maven environment, the code
should compile fine without mentioned imports as the only relation to
them are string literals representing the annotation classes (when
searching the classpath for popular injection annotations) - [this,
however is not true for the test classpath].

@Johan
I'll try to upload some jars later today and maybe get a snapshot
version hosted on the sonatype oss repo.

@Szczepan
I have to think a bit longer on your first question.

And if I understood the second one correctly: what is important is the
return type and the parameters of the request are ignored. In the
proposed implementation the underlying Mockito is told to stub all
methods that return objects of specified type regardless their
parameters (i.e. in when stubbing in place of parameters the any()
matcher is used for objects and a correponding anyPrimitive() matcher
for primitives). And this is done behind the scenes.

On May 3, 10:38 am, Brice Dutheil <brice.duth...@gmail.com> wrote:
> Hi,
>
> This is very cool, I like the idea.
> The only point dislike a bit is having dependency on CDI or seam, etc, not
> every project needs such dependencies.
>
> Also, did you check out the trunk, mockito has now constructor dependency
> injection mechanism. However this is still based on having mocks declared in
> the test.
>
> Anyway this is a very nice experiment :)
>
> --
> Bryce
>

> 2011/5/3 Szczepan Faber <szcze...@gmail.com>

>
> > Exactly.
>
> > Another question is what to do you do when request to collaborator needs
> > formal parameters.
>
> > Good stuff
> > Szczepan

> > 03-05-2011 09:03 użytkownik "Johan Haleby" <johan.hal...@gmail.com>

[Bartosz Bańkowski]

I like the idea a lot! For sure I will take a closer look at it.

Best regards,
Bartosz

On Mon, May 2, 2011 at 10:30 PM, marekdec <mare...@gmail.com> wrote:

[marekdec]

I uploaded the main artifacts to the project downloads section:
http://code.google.com/p/mockarro/downloads/list, both of them are
required on the classpath (you'll also need the dependency injection
framework of your choice, mockarro is capable of recognizing injection
annotations provided by JEE6, Seam 2, Spring, JEE5 in this order - at
list one of them must exist on the classpath in order to perform an
automatic injection; otherwise you can create your own InjectionPoint:
http://mockarro.googlecode.com/svn/trunk/docs/mockarro-injector/site/apidocs/index.html
and pass it to the initSut method) .

I also added some links to the generated maven site and the javadocs
to the googlecode external links section.
Anyhow, I'll try to make all of this a bit better soon.

thanks,
Marek

On May 3, 6:50 pm, Bartosz Bańkowski <bbankow...@gmail.com> wrote:
> I like the idea a lot! For sure I will take a closer look at it.
>
> Best regards,
> Bartosz
>

> On Mon, May 2, 2011 at 10:30 PM, marekdec <marek...@gmail.com> wrote:
> > Hey guys,
> > dunno really if there's any better place to post this kind of things
> > (does sth like mockito-dev exist?), anyhow, recently I've been
> > thinking on mocking and unit testing in general and I came up with
> > some ideas. My thoughts where inspired by Mockito and maybe what I
> > produced could be of some help in the future.

> > Checkout my Mockarro experiment athttp://code.google.com/p/mockarro/.

[Szczepan Faber]

Sounds good. Guys, don't hesitate to share thoughts on testing experience with this feature.

Cheers!
Szczepan

[Felix Leipold]

Hi Marek,

You are happily claiming that "Mockito's when idiom is an implicit and
unwanted verification of an interaction with a collaborator"
This problem could easily be mitigated by replacing:
when(personDao.getPerson("123-45-6789")).thenReturn(zeus);
with
when((Person)any()).thenReturn(zeus);

If you really care about the right parameter value being passed in you
can use an *additional* verify.
Also you claim to be not interested in the interaction with the
personDao. This seems quite arbitrary as interacting with the DAO is
half of what the method does. If you don't care about the interaction
you probably don't care that much about the whole method. I concede
that this is only an example method, but if this what real code I
wouldn't write a unit test for a two-line ;-).

From the example I don't see the advantage over Mockito.

Cheers,
Felix

[marekdec]

Hi Felix,

> I concede
> that this is only an example method, but if this what real code I
> wouldn't write a unit test for a two-line ;-).

This, indeed, is an example method so not writing a test is not an
option :)

Are you sure that the replacement you are suggesting is:

> when(personDao.getPerson("123-45-6789")).thenReturn(zeus);
> with
> when((Person)any()).thenReturn(zeus);

and not:
when(personDao.getPerson(anyString())).thenReturn(zeus); ?

I completely agree with the statement that when you care about
parameters passed to your methods, then verification is desired. The
question is if you really care about the parameters and the method
signature when stubbing. Note that with the advent of 'spying over
mocking' philosophy, stubbing and verification were intentionally
separated. In other words, a 'when' declaration does not ensure you
that a specified method with specified parameters was called. You
could easily add an extra 'when' statement to the test method and it
will not fail. The real advantage of the 'when' idiom over what I
proposed is when's precision. There is no better way of selecting a
method for stubbing than explicitly specifing its name and params.

And of course, verification of the interactions is essential in many
situations. It's just I believe that a verification should be explicit
and it should be a consious choice of the user.

The intention of my proposal is to enhance the existing mocking
frameworks and I can imagine current Mockito functionality and
Mockarro style stubbing to live on the same level (given that anything
of what I'm stating here is true - but that is why I called it an
experiment). I can imagine that the Mockarro managed mocks and good
old style Mockito mocks are used within a single test. Mockarro would
be given a subset of mocks created and managed by the client, it would
generate the rest of the mocks necessary for the initialization of the
unit under test. Then all of them would be injected into the unit
under test. The mockarro style stubbing would be applied to the
complete set of mocks, while the client managed mocks would be used
only when explicit verification is needed (and sometimes when
precision is needed for stubbing).

Also, although it is somehow an incidental consequence of the way
Mockarro creates the mock objects, it is not necessary to create mocks
when using Mockarro (I am aware that @InjectMocks made the things much
easier, but still you have to declare them).

what do you think?

Thanks for your words,
Marek

On May 4, 3:29 pm, Felix Leipold <felix.leip...@gmail.com> wrote:
> Hi Marek,
>
> You are happily claiming that "Mockito's when idiom is an implicit and
> unwanted verification of an interaction with a collaborator"
> This problem could easily be mitigated by replacing:
> when(personDao.getPerson("123-45-6789")).thenReturn(zeus);
> with
> when((Person)any()).thenReturn(zeus);
>
> If you really care about the right parameter value being passed in you
> can use an *additional* verify.
> Also you claim to be not interested in the interaction with the
> personDao. This seems quite arbitrary as interacting with the DAO is
> half of what the method does. If you don't care about the interaction
> you probably don't care that much about the whole method. I concede
> that this is only an example method, but if this what real code I
> wouldn't write a unit test for a two-line ;-).
>
> From the example I don't see the advantage over Mockito.
>
> Cheers,
> Felix
>

> On Mon, May 2, 2011 at 10:30 PM, marekdec <marek...@gmail.com> wrote:
> > Hey guys,
> > dunno really if there's any better place to post this kind of things
> > (does sth like mockito-dev exist?), anyhow, recently I've been
> > thinking on mocking and unit testing in general and I came up with
> > some ideas. My thoughts where inspired by Mockito and maybe what I
> > produced could be of some help in the future.

> > Checkout my Mockarro experiment athttp://code.google.com/p/mockarro/.

[Piotr Przybylak]

2011/5/3 Szczepan Faber <szcz...@gmail.com>

It is a very cool idea. What if the inputs are less 'modelled', like
Strings for example?

Then you have a problem.

Which is a good thing. Probably.

It drives you toward more 'modelled' design.

Best regards
Piotr Przybylak

[Piotr Przybylak]

Hi

One thing about example on project main page:

Person zeus = createZeusWithSSNEqualTo("123-45-6789");

It actually doesn't matter in this example what SSN is set inside zeus object, so it should probably be:

Person zeus = createZeus();

And since most of us doesn't know a lot about Greek Gods probably even better:

Person zeus = createPersonWithNumberOfChildrenEqualTo(71);

The idea seems interesting, but I think it would help me understand it, if you could provide some more examples of test using these approach.

Maybe some less trivial, or even maybe show steps in TDD process, where you use Mocarro to drive the test, implementation (and refactoring?).

-- 
Best regards
Piotr Przybylak

2011/5/2 marekdec <mare...@gmail.com>

[Szczepan Faber]

> It drives you toward more 'modelled' design.

True enough. :)

I guess I would mostly take advantage of this new idea when:
-I don't care about the parameters and I don't care about the method name
-or specifying the method name & params in somewhat a hindrance.

>or even maybe show steps in TDD process

Yeah, interesting. If I specify a method name & params in the test I
can drive the implementation slightly easier. OTOH I can drive it as
well from the code xD.

Cheers,
Szczepan

[marekdec]

@Piotr,

You are right, the example has been updated.

I'll try to come up with some better set of examples this weekend.

Thanks a lot,
Marek

On May 5, 2:55 pm, Piotr Przybylak <piotr.przyby...@gmail.com> wrote:
> Hi
>
> One thing about example on project main page:
>
> Person zeus = createZeusWithSSNEqualTo("123-45-6789");
>
> It actually doesn't matter in this example what SSN is set inside zeus
> object, so it should probably be:
>
> Person zeus = createZeus();
>
> And since most of us doesn't know a lot about Greek Gods probably even
> better:
>
> Person zeus = createPersonWithNumberOfChildrenEqualTo(71);
>
> The idea seems interesting, but I think it would help me understand it, if
> you could provide some more examples of test using these approach.
> Maybe some less trivial, or even maybe show steps in TDD process, where you
> use Mocarro to drive the test, implementation (and refactoring?).
>
> --
> Best regards
> Piotr Przybylak
>

> 2011/5/2 marekdec <marek...@gmail.com>

>
> > Hey guys,
> > dunno really if there's any better place to post this kind of things
> > (does sth like mockito-dev exist?), anyhow, recently I've been
> > thinking on mocking and unit testing in general and I came up with
> > some ideas. My thoughts where inspired by Mockito and maybe what I
> > produced could be of some help in the future.

> > Checkout my Mockarro experiment athttp://code.google.com/p/mockarro/.