How to use description method of org.mockito.internal.verification.VerificationModeFactory class

You have 3 possibilities to solve this:

Abstract factory: Instead of using a static method, use a concrete factory class:

public abstract class AppleFactory {
    public Apple createInstance(final String str);
}

public class AppleFactoryImpl implements AppleFactory {
    public Apple createInstance(final String str) { // Implementation }
}

In your test class, mock the factory:

@RunWith(MockitoJUnitRunner.class)
public class MyClassTest {

    @Mock
    private AppleFactory appleFactoryMock;

    @Mock
    private Apple appleMock;

    @InjectMocks 
    MyClass myClass;

    @Before
    public void setup() {
        when(appleFactoryMock.createInstance(Matchers.anyString()).thenReturn(appleMock);
    }

    @Test
    public void myMethod(){
     ...
     ...
     ...
    }
}

PowerMock: Use PowerMock to create a mock of a static method. Look at my answer to a relevant question to see how it's done.

Testable class: Make the Apple creation wrapped in a protected method and create a test class that overrides it:

public class MyClass {
   private Apple apple;

   public void myMethod() {
       apple = createApple();
       ....
       ....
       ....
   }

   protected Apple createApple() {
       return AppleFactory.createInstance(someStringVariable);
   }
}


@RunWith(MockitoJUnitRunner.class)
public class MyClassTest {

    @Mock
    private Apple appleMock;

    @InjectMocks 
    MyClass myClass;

    @Test
    public void myMethod(){
     ...
     ...
     ...
    }

    private class TestableMyClass extends MyClass {
       @Override
       public void createApple() {
          return appleMock;
       }
    }
}

Of course, in your test class you should test TestableMyClass and not MyClass.

I'll tell you my opinion on each of the methods:

1. The abstract factory method is the best one - This is a clear design that hides the implementation details

2. The testable class - Is the second option which requires minimum changes

3. The PowerMock option is my least favorite - Instead of going for a better design, you ignore and hide your problem. But that's still a valid option.

HttpResponse httpResponse = mock(HttpResponse.class);

see this: Mocking Apache HTTPClient using Mockito

How about

when( method-call ).thenReturn( value1, value2, value3 );

You can put as many arguments as you like in the brackets of thenReturn, provided they're all the correct type. The first value will be returned the first time the method is called, then the second answer, and so on. The last value will be returned repeatedly once all the other values are used up.

Your imports only include the matchers from hamcrest-core, which are in CoreMatchers:

import static org.hamcrest.CoreMatchers.*;

The hasProperty and hasSize methods are only in the Matchers class of hamcrest-library, which includes a larger set of matchers. Try to change your import to the following:

import static org.hamcrest.Matchers.*;

If this does not work, you might only be depending on hamcrest-core. In this case, change your dependency to the hamcrest-library or hamcrest-all artifact. An example for adding this dependency for Maven is below. See the Hamcrest GitHub page for some more details.

<dependency>
    <groupId>org.hamcrest</groupId>
    <artifactId>hamcrest-library</artifactId>
    <version>1.3</version>
</dependency>

MethodSorters is a new class introduced after Junit 4.6 release. This class declared three types of execution order, which can be used in your test cases while executing them.

1. NAME_ASCENDING(MethodSorters.NAME_ASCENDING) - Sorts the test methods by the method name, in lexicographic order.

2. JVM(null) - Leaves the test methods in the order returned by the JVM. Note that the order from the JVM my vary from run to run.

3. DEFAULT(MethodSorter.DEFAULT) - Sorts the test methods in a deterministic, but not predictable, order.

.

import org.junit.FixMethodOrder;
import org.junit.Test;
import org.junit.runners.MethodSorters;

//Running test cases in order of method names in ascending order

@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class OrderedTestCasesExecution {

    @Test
    public void secondTest() {
        System.out.println("Executing second test");
    }

    @Test
    public void firstTest() {
        System.out.println("Executing first test");
    }

    @Test
    public void thirdTest() {
        System.out.println("Executing third test");
    }
}

Output:

Executing first test
Executing second test
Executing third test

Reference: http://howtodoinjava.com/2012/11/24/ordered-testcases-execution-in-junit-4/

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

Actually they are technically the same. When Mockito was first created, we were talking about stubs, so the vocabulary followed that idea. Later people thought it was better to think in interactions rather that technical terms, so the vocabulary followed the when ... then ... style. This change in vocabulary helps people to think about interactions, messaging between object. Which is the most interesting idea (message passing) thing in an object oriented language (quoting Alan Kay).

Nowadays testing approach has evolved to Behavior Driven Development (from Dan North), which is almost the same thing but focus even more on the behavior at design time. To reflect that thinking, people asked Mockito to offer an API that reflect that change. So you also use given ... will ... style from BDDMockito

given(the_type.performs_that()).willReturn(something)

This is my preferred vocabulary now as I use tests to drive my objects design.

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.

If you find yourself creating test classes (other than the classes containing actual tests), then you've defeated the purpose of having a mocking framework.

Create your mocks in your testcases:

 @Test
 public void testGreetingGenerator() {
      Person mockPerson = mock(Person.class);
      when(mockPerson.getName()).thenReturn("Alan");

      GreetingGenerator greeting = new GreetingGenerator(mockPerson);
      assertEquals("Hello Alan", greeting.getGreeting());
 }

If you are using the same mock in many tests, by all means make the mock a field, and put the mock creation into an @Before method.

 @Before
 public void setUp() {
      mockPerson = mock(Person.class);
      when(mockPerson.getName()).thenReturn("Alan");
 }

 @Test
 public void testGreetingGenerator() {
      GreetingGenerator greeting = new GreetingGenerator(mockPerson);
      assertEquals("Hello Alan", greeting.getGreeting());
 }

You can create a "basic" mock in setUp() and add more mocked behaviour to it in the individual testcases. Remember that setUp() gets called before each test, so you get fresh objects in each test.

If the mock creation gets too long and complex, it's fine to move it into a method (static or otherwise), and if necessary decompose that method into lots of smaller ones.

However, if your test code gets too complicated, think of it as a warning that perhaps the unit under test has too many dependencies and needs to be redesigned for testability.

Mocking is for unit testing. In the example above, the unit I am testing is GreetingGenerator. I am not intending to test Person here, so it is better to use a mock Person than a real one. That way if something about Person breaks, my Person tests will fail but my GreetingGenerator tests will keep working.

However that means that those tests don't validate that your Person and GreetingGenerator classes interoperate properly, and that's why as well as unit tests, you should have integration tests.

If you know a class is just for value objects, there's little benefit in using a mock.