How to use testUnrelatedClasses method of org.mockito.internal.matchers.apachecommons.EqualsBuilderTest class

Although I fundamentally agree with Nick Holt's answer, I thought I should point out that mockito allows to do what you ask with the following call :

Foo mock = Mockito.mock(Foo.class, withSettings().extraInterfaces(Bar.class));

Obviously you'll have to use the cast: (Bar)mock when you need to use the mock as a Bar but that cast will not throw ClassCastException

Here is an example that is a bit more complete, albeit totally absurd:

import static org.junit.Assert.fail;
import org.junit.Test;
import static org.mockito.Mockito.*;
import org.mockito.Mockito;
import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.*;
import org.hamcrest.Matchers;

import java.util.Iterator;


public class NonsensicalTest {


    @Test
    public void testRunnableIterator() {
        // This test passes.

        final Runnable runnable = 
                    mock(Runnable.class, withSettings().extraInterfaces(Iterator.class));
        final Iterator iterator = (Iterator) runnable;
        when(iterator.next()).thenReturn("a", 2);
        doThrow(new IllegalStateException()).when(runnable).run();

        assertThat(iterator.next(), is(Matchers.<Object>equalTo("a")));

        try {
            runnable.run();
            fail();
        }
        catch (IllegalStateException e) {
        }
    }

Spring uses commons-logging which auto-detects the logging framework to use. There are various ways to tune which logging framework will be chosen so the first thing to do is to make sure commons-logging binds to log4j.

To do that, start your application with an additional flag -Dorg.apache.commons.logging.diagnostics.dest=STDOUT that will output the result of the discovery process.

commons-logging delegate to log4j

You now need to make sure that log4j is initialise with the expected configuration. By default, log4j searches for a log4j.xml file at the root of the classpath and fallbacks to log4j.properties if it does not find one. It could be possible that one of the library you are using has (wrongly) a log4j.xml file at the root.

To debug log4j, run your application again with an additional flag -Dlog4j.debug=true. This will output the exact loggers and the location of the configuration file.

commons-logging does not delegate to log4j

If commons-logging does not delegate to log4j, this means that another logging framework is involved. The most common scenario is that your application ships with jcl-over-slf4j.jar, a drop-in replacement of commons-logging that uses slf4j behind the scene.

In this scenario, Spring uses commons-logging that is configured to delegate to slf4j. So, essentially, Spring is using slf4j. But slf4j is a simple logging facade and needs a binding to an actual framework.

SINCE 1.6.0 If no binding is found on the class path, then SLF4J will default to a no-operation implementation.

Once you have found the binding library (it could be logback or log4j for instance), check the configuration of the logging framework that slf4j is bound to.

In this particular case, you probably have logback in your classpath. As it is a pure implementation of slf4j, it does not need a binding library and it logs in debug if no configuration file is provided, which matches your problem actually. To fix your issue, exclude logback from your dependencies and add slf4j-log4j12 to configure slf4j with log4j.

Edit: updated with various comments

when(mock.someMethod(any()).thenReturn(yourValue);

The any() matcher basically says you can have any value or a null. Check out the documentation at mockito, especially the section on Argument Matchers.

You should also mock the next() method to have it return true the first time it's called, as mockito will return false by default.

Mockito.when(resultSetMock.next()).thenReturn(true).thenReturn(false);

Let me begin by saying you are on the right track by using Constructor Injection and not Field Injection(which makes writing tests with mocks much simpler).

public class MyServiceImplTest 
{
    private MyDataService myDataService;
    private NyService myService;

    @Mock
    private MyRepository myRepository;

    @Before
    public void setUp() {
        MockitoAnnotations.initMocks(this); // this is needed for inititalizytion of mocks, if you use @Mock 
        myDataService = new MyDataServiceImpl(myRepository);
        myService = new MyServiceImpl(myDataService);
    }

    @Test
    public void getById_ValidId() {

        doReturn(someMockData).when(myRepository).findOne("1");
        MyObject myObject = myService.getById("1");

        //Whatever asserts need to be done on the object myObject 
    }
}

The call goes all the way from your service --> dataService. But only your repository calls are mocked.
This way you can control and test all the other parts of your classes(both service and dataService) and mock only repository calls.

Mockito 2 now supports final classes and methods!

But for now that's an "incubating" feature. It requires some steps to activate it which are described in What's New in Mockito 2:

Mocking of final classes and methods is an incubating, opt-in feature. It uses a combination of Java agent instrumentation and subclassing in order to enable mockability of these types. As this works differently to our current mechanism and this one has different limitations and as we want to gather experience and user feedback, this feature had to be explicitly activated to be available ; it can be done via the mockito extension mechanism by creating the file src/test/resources/mockito-extensions/org.mockito.plugins.MockMaker containing a single line:

mock-maker-inline

After you created this file, Mockito will automatically use this new engine and one can do :

 final class FinalClass {
   final String finalMethod() { return "something"; }
 }

 FinalClass concrete = new FinalClass(); 

 FinalClass mock = mock(FinalClass.class);
 given(mock.finalMethod()).willReturn("not anymore");

 assertThat(mock.finalMethod()).isNotEqualTo(concrete.finalMethod());

In subsequent milestones, the team will bring a programmatic way of using this feature. We will identify and provide support for all unmockable scenarios. Stay tuned and please let us know what you think of this feature!

I have two critiques to that approach... and please bear in mind that my knowledge of your context is almost nil, which means that what I suggest here might not work for you.

I've only once experienced a problem like the one you mentioned, and it was a symptom that there was too much coupling between the objects because the responsbilities were way to broad. Since then I use a Domain-Driven Design approach and I haven't had this problem again.

I prefer to use Test-Data Builders to create test data. This approach allows me to have a template of what I want to build, and just replace the bits I'm interested in the test. If you decide to go this way, I strongly suggest you to use a tiny library called Make-It-Easy that simplifies the creation of these builders.

And two suggestions

If you have some time, I suggest you to

1. Watch a presetation called The Deep Synergy Between Testability and Good Design by Michael Feathers - Part of the talk is about something very similar to what you're experiencing.
2. Read the book Growing Object-Orieted Systems, Guided by Tests (aka GOOS), it has all sorts of insights about how to write simple, amazing, testable code.

Updating my Android Studio to version 3.3 AND removing

testOptions {
    execution 'ANDROID_TEST_ORCHESTRATOR'
}

worked

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");
    }
}