How to use StubbingWithAdditionalAnswersTest class of org.mockitousage.stubbing package

It looks like you're mocking out the only call you're making to production code.

In other words, your test says:

• When I call saveData(), fake the result to return true
• Now call saveData() - yay, the result was true!

None of your production code is being calls at all, as far as I can see.

The point of mocking is to mock out dependencies from your production class, or (sometimes, though I prefer not to) to mock out some methods of your production class that the code you're actually testing will call.

You should probably be mocking out the dependencies of Leaderboard rather than Leaderboard itself. If you must mock out saveData(), you should be testing the methods that call saveData()... check that they save the right data, that they act correctly when saveData() returns false, etc.

If you are using Spring (the spring-test library specifically), you can simply use ReflectionTestUtils.setField instead of Whitebox.setInternalState

Difference between a Spy and a Mock

When Mockito creates a mock – it does so from the Class of a Type, not from an actual instance. The mock simply creates a bare-bones shell instance of the Class, entirely instrumented to track interactions with it. On the other hand, the spy will wrap an existing instance. It will still behave in the same way as the normal instance – the only difference is that it will also be instrumented to track all the interactions with it.

In the following example – we create a mock of the ArrayList class:

@Test
public void whenCreateMock_thenCreated() {
    List mockedList = Mockito.mock(ArrayList.class);

    mockedList.add("one");
    Mockito.verify(mockedList).add("one");

    assertEquals(0, mockedList.size());
}

As you can see – adding an element into the mocked list doesn’t actually add anything – it just calls the method with no other side-effect. A spy on the other hand will behave differently – it will actually call the real implementation of the add method and add the element to the underlying list:

@Test
public void whenCreateSpy_thenCreate() {
    List spyList = Mockito.spy(new ArrayList());
    spyList.add("one");
    Mockito.verify(spyList).add("one");

    assertEquals(1, spyList.size());
}

Here we can surely say that the real internal method of the object was called because when you call the size() method you get the size as 1, but this size() method isn’t been mocked! So where does 1 come from? The internal real size() method is called as size() isn’t mocked (or stubbed) and hence we can say that the entry was added to the real object.

Source: http://www.baeldung.com/mockito-spy + self notes.

You don't normally set properties on your mocked objects; instead, you do some specific thing when it's invoked.

when(slingHttpRequest.getAttribute("search")).thenReturn(someObject);

You can use PowerMockito along with Mockito to mock static methods:

@RunWith(PowerMockRunner.class)
@PrepareForTest(ServiceLoader.class)
public class PowerMockingStaticTest
{
    @Mock
    private ServiceLoader mockServiceLoader;

    @Before
    public void setUp()
    {
        PowerMockito.mockStatic(ServiceLoader.class);
        Mockito.when(ServiceLoader.load(Mockito.any(Class.class))).thenReturn(mockServiceLoader);
    }

    @Test
    public void test()
    {
        Assert.assertEquals(mockServiceLoader, ServiceLoader.load(Object.class));
    }
}

if you do a employee = new Employee(param1, param2); you may as well skip @InjectMocks.

It is supposed to do the following:

@InjectMocks
ClassUnderTest cut;

@Mock
Dependency1 dep1;
@Mock
Dependency2 dep2;

@Before
public void setup() {
  initMocks(this);
}

omitting @InjectMocks the same behaviour can be achieved with the following code:

ClassUnderTest cut;

@Mock
Dependency1 dep1;
@Mock
Dependency2 dep2;

@Before
public void setup() {
  initMocks(this);
  cut = new ClassUnderTest(dep1, dep2);
}

In your specific case, you should mock param1 and param2. Never call the constructor manually when using @InjectMocks.

Mockito comes with a helper class to save you some reflection boiler plate code:

import org.mockito.internal.util.reflection.Whitebox;

//...

@Mock
private Person mockedPerson;
private Test underTest;

// ...

@Test
public void testMethod() {
    Whitebox.setInternalState(underTest, "person", mockedPerson);
    // ...
}

Update: Unfortunately the mockito team decided to remove the class in Mockito 2. So you are back to writing your own reflection boilerplate code, use another library (e.g. Apache Commons Lang), or simply pilfer the Whitebox class (it is MIT licensed).

Update 2: JUnit 5 comes with its own ReflectionSupport and AnnotationSupport classes that might be useful and save you from pulling in yet another library.

You simply forgot to add the dependencies to your project which are according to the pom file:

<dependency>
  <groupId>net.bytebuddy</groupId>
  <artifactId>byte-buddy</artifactId>
  <version>1.3.16</version>
  <scope>runtime</scope>
</dependency>
<dependency>
  <groupId>org.objenesis</groupId>
  <artifactId>objenesis</artifactId>
  <version>2.1</version>
  <scope>runtime</scope>
</dependency>

In other words you need to add byte-buddy 1.3.16 and objenesis 2.1 to your project too.

More details here

As you pointed out, it is not possible to mock static methods with Mockito and since you do not wanna use Powermock or other tools, you can try something as follows in your tests.

1. Create test authentication object

   Authentication auth = new ... // create instance based on your needs and with required attributes or just mock it if you do not care

2. Mock security context

   SecurityContext context = mock(SecurityContext.class);

3. Ensure your mock returns the respective authentication

   when(context.getAuthentication()).thenReturn(auth);

4. Set security context into holder

   SecurityContextHolder.setContext(securityContext);

Now every call to SecurityContextHolder.getContext().getAuthentication() should return authentication object created in step 1.