[mockito] Mocking "new" operator

[jg]

Is there any way of inserting a mock on an object that is instantiated
with the "new" operator?

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

[James Carr]

Am I misunderstanding? If you are wanting to install a mock on an
object instance you can use a spy to do this. Then you will have a
real object with the capability to verify interactions, capture
messages passed to it, and stub methods out. You can either use
Mockito.spy or the @Spy annotation.

I posted a bit on using the @Spy annotation recently on my blog:
http://blog.james-carr.org/2010/04/22/mockito-spy-annotation/

Thanks,
James

[jg]

Ok ... I get the "spy" functionality... it is a way of using the real
object and intercepting specified method calls; that is useful.

I was more thinking the following scenario... if the ClassUnderTest
instantiates an object using "new" is there anyway of intercepting the
"new" and returning a fully mocked object?

JG

On May 18, 9:20 am, James Carr <james.r.c...@gmail.com> wrote:
> Am I misunderstanding? If you are wanting to install a mock on an
> object instance you can use a spy to do this. Then you will have a
> real object with the capability to verify interactions, capture
> messages passed to it, and stub methods out. You can either use
> Mockito.spy or the @Spy annotation.
>
> I posted a bit on using the @Spy annotation recently on my blog:http://blog.james-carr.org/2010/04/22/mockito-spy-annotation/
>
> Thanks,
> James
>

> On Tue, May 18, 2010 at 7:41 AM, jg <javi...@us.ibm.com> wrote:
> > Is there any way of inserting a mock on an object that is instantiated
> > with the "new" operator?
>
> > --
> > 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 athttp://groups.google.com/group/mockito?hl=en.

>
> --
> 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 athttp://groups.google.com/group/mockito?hl=en.

[James Carr]

Nope... you don't want to introduce mocks that way. Instead, you
should have dependencies passed into the class under test and
introduce a mock that way.

[jg]

Well two things...

1. For my education... when you say "passed into" I assume you mean
passed in as an argument to the methodUnderTest or passed in the
constructor of the classUnderTest in which in case it would probably
save it in an instance variable and make it available to the other
methods in the CUT. Is this what you mean?

2. This is legacy code and it does a "new" to instantiate an object...
In this scenario is there anything the Mockito could do? I do not
think I can spy the instantiated class since I do not instantiate it
in my Unit Test but in the CUT.

jg

[Bartosz Bańkowski]

For legacy code you can extract method that instantiate the object you
want to mock. You make this method at least package-private and then
you can either override it in your test or use a spy and stub this
method.

Best regards,
Bartosz

[James Carr]

I mean buy injecting the dependency... imho it's bad to have an object
create it's own dependencies, they should be injected instead.

I think this is a good recent post about the subject:
http://googletesting.blogspot.com/2008/07/how-to-think-about-new-operator-with.html


Thanks,
James

[Chris Bartling]

Javier,

You might want to step back and understand your design a little bit.  Mocking works best when your class under test does not take on the responsibility of constructing its collaborators.  If your class in your current code base is taking on this responsibility, you should refactor that responsibility to some method that you can overridden or a factory that you can mock.  Ultimately, you'd prefer to use dependency inversion (of which dependency injection is one flavor of) to facilitate this decoupling.  Much looser coupling between your object under test and its collaborators.  One smell that I look for is the importing of concrete classes.  If you see this, in most situations its a sign that your class knows too much about its collaborators.

Refactoring a code base to alleviate classes from construction responsibilities is a common legacy smell.  I've encountered it many times and it's fairly straightforward to fix.

http://en.wikipedia.org/wiki/Dependency_inversion_principle

http://en.wikipedia.org/wiki/Dependency_injection

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

HTH,

-- chris -- 

On Tue, May 18, 2010 at 10:01 AM, jg <jav...@us.ibm.com> wrote:

[Kartik Kumar]

Even though it is a code smell, it is still possible to do it. You need a remapper framework.  There is a framework called PowerMock that works on top of Mockito and EasyMock to provide this functionality. Take a look at this link http://code.google.com/p/powermock/wiki/MockitoUsage

[jg]

I am actually aware of PowerMock and have been playing with it,
however, I am also using OpenEJB and there seems to be a problem
integrating these two. Also I know you can always factor out
instantiation to a method or factory but this is not always possible
when working with legacy code.

Thanks for your thoughts everyone they have been helpful.

jg

On May 18, 12:06 pm, Kartik Kumar <krishnan.1...@gmail.com> wrote:
> Even though it is a code smell, it is still possible to do it. You need a
> remapper framework.  There is a framework called PowerMock that works on top
> of Mockito and EasyMock to provide this functionality. Take a look at this

> linkhttp://code.google.com/p/powermock/wiki/MockitoUsage

>
> On Tue, May 18, 2010 at 8:16 AM, Chris Bartling <chris.bartl...@gmail.com>wrote:
>
>
>
> > Javier,
>
> > You might want to step back and understand your design a little bit.
> >  Mocking works best when your class under test does not take on the
> > responsibility of constructing its collaborators.  If your class in your
> > current code base is taking on this responsibility, you should refactor that
> > responsibility to some method that you can overridden or a factory that you

> > can mock.  Ultimately, you'd prefer to use *dependency inversion* (of
> > which *dependency injection* is one flavor of) to facilitate this

> > decoupling.  Much looser coupling between your object under test and its
> > collaborators.  One smell that I look for is the importing of concrete
> > classes.  If you see this, in most situations its a sign that your class
> > knows too much about its collaborators.
>
> > Refactoring a code base to alleviate classes from construction
> > responsibilities is a common legacy smell.  I've encountered it many times
> > and it's fairly straightforward to fix.
>
> >http://en.wikipedia.org/wiki/Dependency_inversion_principle
>

> > <http://en.wikipedia.org/wiki/Dependency_inversion_principle>
> >http://en.wikipedia.org/wiki/Dependency_injection
>
> > <http://en.wikipedia.org/wiki/Dependency_injection>
> >http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

>
> > <http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod>HTH,
>
> > -- chris --
>

> >> mockito+u...@googlegroups.com<mockito%2Bunsu...@googlegroups.com>
> >> .

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

> >> > >> --
> >> > >> 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<mockito%2Bunsu...@googlegroups.com>
> >> .

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

> >> > > --
> >> > > 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<mockito%2Bunsu...@googlegroups.com>
> >> .

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

> >> > --
> >> > 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<mockito%2Bunsu...@googlegroups.com>
> >> .

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

> >> --
> >> 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<mockito%2Bunsu...@googlegroups.com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/mockito?hl=en.
>
> >  --
> > 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<mockito%2Bunsu...@googlegroups.com>
> > .