How to use withCodeSourceUrls method of org.mockitoutil.ClassLoaders class

HttpResponse httpResponse = mock(HttpResponse.class);

see this: Mocking Apache HTTPClient using Mockito

In general, testing a class's internal function calls makes your tests far too fragile. When unit testing, you only want to see that the class as a whole is doing what it is supposed to do. You are supposed to intentionally ignore the internals.

Ignoring the internals has a lot of useful benefits. Mainly, if you change the methods -- as long as the public interface stays the same -- your tests will all still pass. Yay. This is the type of stability you want your unit tests to have. Fragile unit tests are almost worse than no unit tests. A fragile test has to be changed every time the code changes even if everything is still working. That provides you with nothing but extra work.

There are exceptions though. I would consider mocking out internal function calls in the following cases:

1) The internal call pulls data from somewhere. For example a database or large file. This is often called a 'boundary' test. We don't want to really set up a database or file to test, so instead we just sub out the function. However, if you find yourself doing this, it probably means that your class should be split into two classes because it is doing too many different things. Make yourself a dedicated database class instead.

2) The internal call does heavy processing that takes a lot of time. In that case, it might make sense to sub out the function instead of waiting. However, once again this might be a sign that you're on the wrong track. You should try to find a way to make things more partitioned so no single step takes that long.

In conclusion, I would highly recommend you do not test at the method level. A class should be a distinct unit. If the class is working everything is fine. This approach give you the testing you need to be secure and the flexibility you need to change things.

@raspacorp

Indeed, if you only test one case, someone could hardcode var = 2 and then pass your test case. But it is your job in designing tests cases to cover enough different cases to be reasonably satisfied that it is behaving appropriately.

As far as tests changing because the code has changed, this is not what you want at all. You want your tests to verify that the responses you are getting are correct for all the different types of cases. As long as the responses are correct, you want to be able to change everything without changing the tests at all.

Imagine a large system with thousands of tests verifing that everything is working right. Now imagine that you want to make a HUGE optimization change that will make things go faster, but change how everything is stored and calculated. What you want your tests to allow you to do is only change code (not tests) and have the tests continually confirm that everything is still working. This is what unit tests are for, not catching every possible line change, but rather to verify that all the calculations and behaviors are corrent.

This is a long time ago question, but here is how i did it, using Mockito spy, create a method which call the parent method in the child class:

public class Child extends Parent {
    /**
     * Shouldn't invoke protected Parent.print() of parent class.
     */
    @Override
    protected String print() {
        // some additional behavior
    return callParent();
    }

    protected callParent()
    {
      super.print();
    }

}

And in the test :

@Test
public void sould_mock_invocation_of_protected_method_of_parent_class() throws Exception {

    // Given
    Child child = Mockito.spy(new Child());
    Mockito.doReturn(null)
           .when(child)
           .callParent();
    // When
    String retrieved = child.print();

    // Then
    Mockito.verify(child, times(1)).callParent(); // verification of child method
    Assert.assertEquals(retrieved, "abc");
}

Note: this test only check we call the parent method in the child class

I found a way to use PowerMock in conjunction with Robolectric.

In addition to the standard PowerMock jars, the PowerMock Junit Rule is also needed. It is described here how to grab it. I used the xstream classloading version, because the objenesis one is very buggy. This is working with PowerMock 1.5.5 and Robolectric 2.3, i cannot speak about the older versions. Also please note that the Java agent should not be included, because from my experience it causes problems.

So if you are using maven, these dependencies should be declared:

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-module-junit4</artifactId>
    <version>${powermock.version}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-module-junit4-rule</artifactId>
    <version>${powermock.version}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-api-mockito</artifactId>
    <version>${powermock.version}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-classloading-xstream</artifactId>
    <version>${powermock.version}</version>
    <scope>test</scope>
</dependency>

Then you have to setup your test class like this:

@RunWith(RobolectricTestRunner.class)
@PowerMockIgnore({ "org.mockito.*", "org.robolectric.*", "android.*" })
@PrepareForTest(Static.class)
public class MyTest {

    @Rule
    public PowerMockRule rule = new PowerMockRule();

    private MyActivity activity;

    @Before
    public void setup() {
        activity = Robolectric.buildActivity(MyActivity.class).create().get();
    }

    @Test
    public void test() throws Exception {
        PowerMockito.mockStatic(Static.class);
        Mockito.when(Static.getCurrentTime()).thenReturn(1);

        Assert.assertEquals(1, activity.getId());
    }
}

• Unit test frameworks: JUnit / TestNG
• Mocking frameworks: JMock / EasyMock / Mockito
• Continuous Integration tools: CruiseControl / Hudson
• Requirements testing: Fit / FitNesse
• Code coverage: Cobertura
• Automated UI testing: Selenium
• Other tools: HTTPUnit / DBUnit
• Mutation Testing PITest
• Contract tester: EqualsVerifier (Ok, full disclosure: I made this one myself.)

Rather than try to translate JMockit code directly, its better to rewrite the tests using Mockito idioms.

Unit tests which use mockito usually follow this form:

1. Create mock objects (often done in setUp, or with annotations)
2. stub any necessary methods using Mockito.when
3. Invoke the code that is being tested.
4. Make any assertions about the state and/or return values of the code being tested.
5. Verify expected interactions using Mockito.verify

I don't know what MockUp actually does, but this looks like it is part of a stub. If you still need to call queue.add, then you can do that in an Answer. If that queue.add was simply used to validate the string1 for each call, then you can do that without a queue.

I stumbled upon this too and the answer is buried quite deep in the docs, so here it is.

Mockito optionally offers advanced mocking features like mocking final classes. For this to work, they use a different mechanism ("mock maker") that is considered experimental and therefore turned off by default. But:

As a convenience, the Mockito team provides an artifact where this mock maker is preconfigured. Instead of using the mockito-core artifact, include the mockito-inline artifact in your project.

I've recently adopted a project that uses JMockit and I think the quality of the code has certainly suffered as a result of the library's ability to mock out static and private methods.

The tests are very brittle because implementation details contained in private methods are being tested (so if I change how the class does something it can break tests, even if what the class does has not been affected).

The code is also littered with calls to static methods - if the developers had not had the ability to mock these out then I think they would have made more effort to de-couple things a little better.

I believe you missed the whole idea of unit testing and mocking.

1. When you are unit testing your UserService, you DO NOT want to use the real UserRepository implementation.
2. You mocked a UserRepository, you do not expect the mock object to immediately behave as the real one. You need to make up its behavior (aka stubbing).
3. You should rarely need to use Spring Runner in unit test.

In order to decide the behavior of the mock object, you gotta know the expected interaction of your system-under-test (SUT, which is the UserService in your case) and its dependencies (UserRepository)

In your case, the test should looks like (haven't compiled, just show you the idea)

public class UserServiceTest {

    @InjectMocks
    UserService userService;

    @Mock
    UserDao mockUserRepository;

    @Before
    public void setUp(){
        MockitoAnnotations.initMocks(this);
    }

    @Test
    public void testFindUser(){
        // Given
        User dummyUser = new User();
        when(mockUserRepository.findByLoginAndPassword(anyString(), anyString()).thenReturn(dummyUser);

        // When
        User result = userService.findUser("first", "teste");

        // Then
        // you are expecting service to return whatever returned by repo
        assertThat("result", result, is(sameInstance(dummUser)));

        // you are expecting repo to be called once with correct param
        verify(mockUserRepository).findByLoginAndPassword("first", "teste");
    }
}