How to use shouldProvideTheNameForClass method of org.mockito.internal.util.ObjectMethodsGuruTest class

Use when(spy.myMethod()).thenReturn(null). This will prevent the spy from invoking the wrapped instance. You have to tell Mockito what to return for a method that returns something. The default behavior for a mock is to return null. The default behavior for a spy is to call the wrapped object. When you stub a method in a spy it prevents the call to the wrapped object and executes the specified behavior.

Per documents of Spy, you could also do doReturn(null).when(spy).myMethod();

Just point that with Mockito you can also use AdditionalMatchers and ArgumentMatchers

import static org.mockito.AdditionalMatchers.not;
import static org.mockito.ArgumentMatchers.eq;

//anything but not "ejb"    
mock.someMethod(not(eq("ejb")));

According its documentation:

Example of using logical and(), not(), or() matchers:

//anything but not "ejb"
mock.someMethod(not(eq("ejb")));

There is more info in this other SO question

Hope it helps

You are chaining method calls on your mocked instance:

@Mock
HttpServletRequest mockedRequest = mock(HttpServletRequest.class);

First of all, you do not need to do both, either use the @Mock annotation or the mock method. Like this, you first assign a Mock and then replace this instance with another mock. I recommend the annotation as it adds some context to the mock such as the field's name. This might already cause your NullPointerException as you however never activate the annotations by calling:

MockitoAnnotations.initMocks(this);

as you do not consequently mock all instances with both measures so far. However, even doing so will further result in your exception, so let's move ahead.

Within friendWebService.createFriendRequest(mockedRequest) you call:

User user = (User) request.getSession().getAttribute("user");
User otherUser = (User) request.getSession().getAttribute("profileuser");

where you call a method on two mocks for which you did not specify any behavior. These mocks do by default return null. You need to specify behavior for this such as:

when(request.getSession()).thenReturn(myMockedSession);

before performing this chained call. Based on this, you can then specify how to react to calls on this mocked instance such as returning your user mocks.

You can set a default answer for a mock. All methods that aren't stubbed will use this default answer.

public void testUnstubbedException() {
    // Create a mock with all methods throwing a RuntimeException by default
    SomeClass someClass = mock( SomeClass .class, new RuntimeExceptionAnswer() );

    doReturn(1).when(someClass).getId(); // Must use doReturn

    int id = someClass.getId(); // Will return 1

    someClass.unstubbedMethod(); // Will throw RuntimeException
}

public static class RuntimeExceptionAnswer implements Answer<Object> {

    public Object answer( InvocationOnMock invocation ) throws Throwable {
        throw new RuntimeException ( invocation.getMethod().getName() + " is not stubbed" );
    }

}

Note that you cannot use when with this functionality, since the method is called before when (How does mockito when() invocation work?) and it will throw a RuntimeException before the mock goes into stubbing mode.

Therefore, you must use doReturn for this to work.

Most important concept in the Gradle java-test-fixtures plugin is stated in their documentation:

[this plugin] will automatically create a testFixtures source set, in which you can write your test fixtures. Test fixtures are configured so that:

• they can see the main source set classes
• test sources can see the test fixtures classes

This plugin will indeed create the following dependencies: main <-- testFixtures , and testFixtures <-- test

In your case, testFixtures module should automatically depend on main sources, and also on main dependencies declared in api scope ( com.my.extenal.project:1.0)

See a similar example in a valid sample project here https://github.com/mricciuti/so-64133013 :

• Simpsons class has access to Person class from main module
• TestHelpers class has access to main dependencies declared in api configuration

Note that testFixtures will not inherit dependencies from the test module: if you need to use such libraries in this module (eg. JUnit, Mockito, ...) you will need to declare explicit dependency , using testFixturesImplementation or testFixturesApi configuration.

See example in core-module

plugins {
    id ("java-library")
    id ("java-test-fixtures")
}
dependencies {
    // Main dependencies
    //   will be available in "testFixture" as well thanks to "api" configuration
    api("org.apache.commons:commons-lang3:3.9")
    api(project(":utils-module"))

    // Testfixture dependencies
        // ==> mockito lib will be available in testFixture module and also in consumer modules (e.g test)
    testFixturesApi("org.mockito:mockito-core:3.5.13")

    // Test dependencies
       // dependencies specific to the "test" module; not visible from "testFixtures"
    testImplementation("org.junit.jupiter:junit-jupiter-api:5.3.1")
    testRuntimeOnly ("org.junit.jupiter:junit-jupiter-engine:5.3.1")
}

For void methods, I think you need to use the doThrow syntax.

So in your case it would be:

doThrow(BookingException.builder().build())
      .when(booking)
      .validate(any());

Another way of dealing with this issue is the following:

/**
 * This method overcomes the issue with the original Mockito.spy when passing a lambda which fails with an error
 * saying that the passed class is final.
 */
@SuppressWarnings("unchecked")
static <T, P extends T> P spyLambda(Class<T> lambdaType, P lambda) {
    return (P) mock(lambdaType, delegatesTo(lambda));
}

Which allows spying the lambda by changing the first method as following:

@Test
void spyingLambda() {
    Supplier<String> spy = spyLambda(Supplier.class, () -> "1");
    spy.get();
}

Hopefully the above examples might help others who encounter the same issue.

Since I didn't get any response here I asked on the Mockito forums. Here is a link to the discussion: https://groups.google.com/d/topic/mockito/hWwcI5UHFi0/discussion

To summarize the answers, technically this would kind of defeat the purpose of mocking. You should really only mock the objects needed by the SystemUnderTest class. Mocking things within objects that are themselves mocks is kind of pointless.

If you really wanted to do it, @spy can help

First off - the call to System.exit() will break your test.

Second - not a good idea to mock the System class. It makes more sense to redirect System.out to a fake or stub.

Third - Reading stuff from System.in will be tricky to do from test as well.

Apart from that: I've taken the liberty to reduce the code for readability:

public class WritesOut {

    public static void doIt() {
           System.out.println("did it!");
    }

}

Test should test if Line was printed to System.out:

import static org.junit.Assert.*;

import java.io.ByteArrayOutputStream;
import java.io.PrintStream;

import org.junit.Test;

public class WritesOutTestUsingStub {

    @Test
    public void testDoIt() throws Exception {
        //Redirect System.out to buffer
        ByteArrayOutputStream bo = new ByteArrayOutputStream();
        System.setOut(new PrintStream(bo));
        MockOut.doIt();
        bo.flush();
        String allWrittenLines = new String(bo.toByteArray()); 
        assertTrue(allWrittenLines.contains("did it!"));
    }

}