Re: [mockito] method with final argument

[Eric Lefevre-Ardant]

No, there are no limitations related to the fact that a parameter might be null (that I'm aware of).

What does your test look like?

On 30 May 2013 17:17, Daan Hoogland <daan.h...@gmail.com> wrote:

Does the limitation on mocking final methods also apply to methods that have a final argument?

I am not sure yet this is my problem but I encountered public T findById(final ID id) and got an exception on the when().thenReturn()

org.mockito.exceptions.misusing.InvalidUseOfMatchersException: 

Misplaced argument matcher detected here:

-> at com.cloud.network.CreatePrivateNetworkTest.setup(CreatePrivateNetworkTest.java:127)

You cannot use argument matchers outside of verification or stubbing.

Examples of correct usage of argument matchers:

    when(mock.get(anyInt())).thenReturn(null);

    doThrow(new RuntimeException()).when(mock).someVoidMethod(anyObject());

    verify(mock).someMethod(contains("foo"))

Also, this error might show up because you use argument matchers with methods that cannot be mocked.

Following methods *cannot* be stubbed/verified: final/private/equals()/hashCode().

at com.cloud.network.CreatePrivateNetworkTest.setup(CreatePrivateNetworkTest.java:127)

...

hi btw, nice to meet you all,

Daan Hoogland

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

[Brice Dutheil]

Hi,

Make sur you don't use a Mockito matcher elsewhere outside stubbing, it may be in another class and using this runner MockitJUnitRunner might help. And also you should ensure the stubbed method is not final.

Otherwise you should show us a snippet of your code, as Eric suggested.

-- Brice

[Daan Hoogland]

Op donderdag 30 mei 2013 18:27:43 UTC+2 schreef Brice het volgende:

Otherwise you should show us a snippet of your code, as Eric suggested.

Here's a extract from the problematic class. The first dao   will pass the when clause. the other three don't. I am at a loss.

package com.cloud.network;

import static org.mockito.Matchers.anyBoolean;
import static org.mockito.Matchers.anyLong;
import static org.mockito.Mockito.when;

import javax.inject.Inject;

import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

import com.cloud.dc.dao.DataCenterDao;
import com.cloud.network.dao.PhysicalNetworkDao;
import com.cloud.network.vpc.dao.PrivateIpDao;
import com.cloud.offerings.dao.NetworkOfferingDao;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations="classpath:/mockitoTest.xml")

public class MockitoTest {

    NetworkServiceImpl networkService = new NetworkServiceImpl();

    @Inject NetworkOfferingDao _networkOfferingDao;
    @Inject PhysicalNetworkDao _physicalNetworkDao;
    @Inject DataCenterDao _dcDao;
    @Inject PrivateIpDao _privateIpDao;

    @Before
    public void setup() throws Exception {
        when(_networkOfferingDao.findById(anyLong())).thenReturn(null);

        when(_physicalNetworkDao.findById(anyLong())).thenReturn(null);

        when(_dcDao.lockRow(anyLong(), anyBoolean())).thenReturn(null);

        when(_privateIpDao.findByIpAndSourceNetworkId(1L, "10.1.1.2")).thenReturn(null);

    }
    @Test
    public void Pass(){
    }
}

[Eric Lefevre-Ardant]

How have you instantiated your dependencies?

I'll take a guess and I assume that they are actually spies over concrete classes.

When using spies, you need to be very careful not to call concrete code while defining their behavior.

Try this instead:

        doReturn(null).when(_networkOfferingDao).findById(anyLong()));

        doReturn(null).when(_physicalNetworkDao).findById(anyLong()));

        doReturn(null).when(_dcDao).lockRow(anyLong(), anyBoolean()));

        doReturn(null).when(_privateIpDao).findByIpAndSourceNetworkId(1L, "10.1.1.2"));

If not using spies, well... Mockito already returns null by default, so I'm not sure what you are trying to achieve.

Eric

PS: see if you can write your test without using SpringJUnit4ClassRunner or the @Inject annotation. I find that this forces you to make the intention of your test a lot clearer.

[Daan Hoogland]

They do not actually return nulls.  This is a trimmed version.  The point is that the first one works, and the second doesn't. The original test has 7 dependencies to a class that is being tested. Only last the three from my example don't work.

Is the doReturn-construct preferable over a thenReturn?

You received this message because you are subscribed to a topic in the Google Groups "mockito" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mockito/Ul9yMcZqnKY/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to mockito+u...@googlegroups.com.

[Eric Lefevre-Ardant]

It is still not clear to me whether they are spies or normal mocks.

Again, spies are tricky. When you write:

        when(_networkOfferingDao.findById(anyLong())).thenReturn(null);

it actually does the following:

1. _networkOfferingDao.findById(anyLong()) : call the actual concrete method
2. execute the when() and replace the (future) calls to the concrete method with the behavior described there. 

The important thing is that your original _networkOfferingDao.findById() method is called! It might throw an exception, or it might not, but this out of the hands of Mockito. I'm guessing that the concrete method _networkOfferingDao.findById(anyLong()) does not throw an exception, but the other methods do. Check with a debugger.

When you write instead:

    doReturn(null).when(_networkOfferingDao.findById(anyLong()));

doReturn() is called before the rest, so Mockito has the opportunity to block the call to the concrete method and you won't get an exception.

[Daan Hoogland]

Ok, thanks for the explanation.  I actually replaced mocks with spies as my test wasn't working. I'll experiment some more and let you know.

One more question: is it possible to reinit mockito e.g. remove the when behaviour in the teardown/@after method?

[Eric Lefevre-Ardant]

Yep, Mockito.reset():

  http://docs.mockito.googlecode.com/hg/org/mockito/Mockito.html#17