How to use can_define_class_in_closed_module method of org.mockito.moduletest.ModuleHandlingTest class

The source and target versions can be set separately for the compile and testCompile goals of the maven compiler plugin. You can change the settings either by defining properties in your pom:

<properties>
    <maven.compiler.source>1.4</maven.compiler.source>
    <maven.compiler.target>1.4</maven.compiler.target>
    <maven.compiler.testSource>1.5</maven.compiler.testSource>
    <maven.compiler.testTarget>1.5</maven.compiler.testTarget>
</properties>

Or by explicit configuration of the compiler plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.4</version>
    <configuration>
        <source>1.4</source>
        <target>1.4</target>
        <testSource>1.5</testSource>
        <testTarget>1.5</testTarget>
    </configuration>
</plugin>

Honestly I am not sure if I really understand your question :P I will try to clarify as much as I can, from what I get from your original question:

First, in most case, you should NOT have any concern on Spring. You rarely need to have spring involved in writing your unit test. In normal case, you only need to instantiate the system under test (SUT, the target to be tested) in your unit test, and inject dependencies of SUT in the test too. The dependencies are usually a mock/stub.

Your original suggested way, and example 2, 3 is precisely doing what I am describing above.

In some rare case (like, integration tests, or some special unit tests), you need to create a Spring app context, and get your SUT from the app context. In such case, I believe you can:

1) Create your SUT in spring app ctx, get reference to it, and inject mocks to it

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("test-app-ctx.xml")
public class FooTest {

    @Autowired
    @InjectMocks
    TestTarget sut;

    @Mock
    Foo mockFoo;

    @Before
    /* Initialized mocks */
    public void setup() {
        MockitoAnnotations.initMocks(this);
    }

    @Test
    public void someTest() {
         // ....
    }
}

or

2) follow the way described in your link Spring Integration Tests, Creating Mock Objects. This approach is to create mocks in Spring's app context, and you can get the mock object from the app ctx to do your stubbing/verification:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("test-app-ctx.xml")
public class FooTest {

    @Autowired
    TestTarget sut;

    @Autowired
    Foo mockFoo;

    @Test
    public void someTest() {
         // ....
    }
}

Both ways should work. The main difference is the former case will have the dependencies injected after going through spring's lifecycle etc. (e.g. bean initialization), while the latter case is injected beforehands. For example, if your SUT implements spring's InitializingBean, and the initialization routine involves the dependencies, you will see the difference between these two approach. I believe there is no right or wrong for these 2 approaches, as long as you know what you are doing.

Just a supplement, @Mock, @Inject, MocktoJunitRunner etc are all unnecessary in using Mockito. They are just utilities to save you typing the Mockito.mock(Foo.class) and bunch of setter invocations.

There are two possible workarounds:

private fun <T> anyObject(): T {
    Mockito.anyObject<T>()
    return uninitialized()
}

private fun <T> uninitialized(): T = null as T

@Test
fun myTest() {
    `when`(mockedBackend).login(anyObject())).thenAnswer { ... }
}

The other workaround is

private fun <T> anyObject(): T {
    return Mockito.anyObject<T>()
}

@Test
fun myTest() {
    `when`(mockedBackend).login(anyObject())).thenAnswer { ... }
}

Here is some more discussion on this topic, where the workaround is first suggested.

You are mocking the object that you're testing. That makes no sense. You should create a real WithDefinitions object and call its real method to test it. If you mock it, by definition, all its methods are replaced by mock implementations that do nothing.

Replace

WithDefinitions withDefinitions = Mockito.mock(WithDefinitions.class);

by something like

WithDefinitions withDefinitions = new WithDefinitions();

You are only asking Mockito to call the real thing on clear, the underlying object is still a fake created by Mockito for you. If you need a real LinkedList then just use the LinkedList - only the most heated purist of BDD would tell you to mock everything around you. I mean, you are not mocking Strings are you?

Mockito author himself has said that calling the real thing should be used scarcely, usually only for testing a legacy code.

If you need to spy on the real object (track the invocations) then Mockito has a feature for this too:

List list = new LinkedList();
List spy = spy(list);

With spy, you can still stub a method if you need. It basically works like a mock, but isn't ;)

The rule S2699 (Tests should include assertions) from the SonarQube Java Analyzer does not perform cross-procedural analysis and only explore body of methods being identified as test method (usually annotated with @Test).

Consequently, if the only assertions which will be called when executing the test method are done by a dedicated method (to avoid duplication), then the rule will raise an issue. This is a known limitation of the rule and we will deal with it only when we will be able to efficiently perform cross-procedural analysis.

Regarding the issues raised by SonarQube on such cases, you can safely mark them as Won't Fix.

Regarding the detected assertions, the rule consider as assertions the usual assert/fail/verify/expect methods from the following (unit test) frameworks :

• JUnit
• Fest (1.x & 2.x)
• AssertJ
• Hamcrest
• Mockito
• Spring
• EasyMock

I wanted to do the same thing, and eventually accomplished it by using the Mockito "spy" function, which wraps a real object with a mock object. All calls to the mock object get forwarded to the real object, except those you are trying to mock. For example:

ObjectMapper om = Mockito.spy(new ObjectMapper());
Mockito.when( om.writeValueAsString(ErrorObject.class)).thenThrow(new JsonProcessingException("") {});

All usages of om will be handled by the underlying ObjectMapper instance until an instance of ErrorObject gets passed in, at which point the JsonProcessingException will be thrown.

The newJsonProcessingException is created as an anonymous class, as it is a protected class and only a sub-class can be instantiated.

Just stumbled into this question while I was searching for its answer. I realized from this github issue that I was using an old version of mockito.

I simply updated from this version

        <dependency>
            <groupId>org.mockito</groupId>
            <artifactId>mockito-all</artifactId>
            <version>1.10.19</version>
            <scope>test</scope>
        </dependency>

to this version

        <dependency>
            <groupId>org.mockito</groupId>
            <artifactId>mockito-core</artifactId>
            <version>3.2.4</version>
            <scope>test</scope>
        </dependency>

The trick was that the artifactId has changed and that Google sends you the link to the older artifactId on lookup for "mockito maven".

You haven't mocked the behavior of getId in externalDependencyObject therefore it is returning null and giving you the NPE when toString() is called on that null.

You need a when(externalDependencyObject.getId()).then...