List of Classes and Methods of org.concurrentmockito package of Mockito Framework

I met the same problem, Add the following dependency resolved this problem.

When you met javax/el/PropertyNotFoundException， That means you missed el-api dependency, you can add the following jar

    <dependency>
        <groupId>javax.el</groupId>
        <artifactId>el-api</artifactId>
        <version>2.2</version>
        <scope>provided</scope>
    </dependency>

or

<dependency>
  <groupId>javax.el</groupId>
  <artifactId>javax.el-api</artifactId>
  <version>3.0.0</version>
  <scope>test</scope>
</dependency>

Then you met ClassNotFoundException:com.sun.el.ExpressionFactoryImpl , You missed el-impl jar:

<dependency>
  <groupId>org.glassfish.web</groupId>
  <artifactId>el-impl</artifactId>
  <version>2.2</version>
  <scope>test</scope>
</dependency>

The method you are mocking is not accessible to the Mockito code.

Because your test code and your code under test are in the same package, the compiler lets you set up your mock that way, but at runtime, the Mockito library has to try to access moveAttachment, but it's not working in your case. This appears to be a bug or known limitation in Mockito as it should support that case, (and in fact, does support it in most cases).

The easiest thing to do would be to make moveAttachment a public method. If that is not an option, then first question whether you want to even mock it. What happens if the real method gets called?

The last option is to use PowerMock to treat the moveAttachment method as a private method and mock it that way.

From an identical issue that I just ran into, I suspect that sample is a mock, and you stubbed sample.getId() elsewhere? That caused this problem in my case, anyhow.

For some reason, Mockito gets upset if one of the arguments you pass to the stub used with doThrow in this way is the result of a method you also mocked. Perhaps it's a re-entrancy check of sorts to avoid infinite loops, I don't know.

Regardless, try replacing sample.getId() with a constant value and that should solve the issue. You could consider using a constant declared in your test for both the mock and any further uses of it. You could then also check that sample.getId() was used by the method you're testing by adding another call to verify.

If I understood the task correctly it could be like this

static boolean isClosed;

public void run() {
    InputStream inputStream = null;
    try {
        inputStream = new FileInputStream(file) {
            @Override
            public void close() throws IOException {
                isClosed = true;
                super.close();
            }
        };
        // more stuff here

Further reading has led me to try using ArgumentCaptors and the following works, although much more verbose than I would like.

ArgumentCaptor<String> argument = ArgumentCaptor.forClass(String.class);

verify(errors, atLeastOnce()).add(argument.capture(), any(ActionMessage.class));

List<String> values = argument.getAllValues();

assertTrue(values.contains("exception.message"));
assertTrue(values.contains("exception.detail"));

Found out that by changing the Async mode to AspectJ fixed the issue:

@EnableCaching
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(lazyInit = true) 
@EnableAsync(mode = AdviceMode.ASPECTJ) // Changes here!!!
public class Main {
    public static void main(String[] args) {
        new SpringApplicationBuilder().sources(Main.class)
                                    .run(args);
    }
}

I'll accept this as a temporary hackish solution until I understand what's the real root cause of this issue.

From the docs:

Sometimes we need to stub with different return value/exception for the same method call. Typical use case could be mocking iterators. Original version of Mockito did not have this feature to promote simple mocking. For example, instead of iterators one could use Iterable or simply collections. Those offer natural ways of stubbing (e.g. using real collections). In rare scenarios stubbing consecutive calls could be useful, though:

when(mock.someMethod("some arg"))
   .thenThrow(new RuntimeException())
  .thenReturn("foo");

//First call: throws runtime exception:
mock.someMethod("some arg");

//Second call: prints "foo"
System.out.println(mock.someMethod("some arg"));

So in your case, you'd want:

when(myMock.doTheCall())
   .thenReturn("You failed")
   .thenReturn("Success");

Technically speaking both "mocks" and "spies" are a special kind of "test doubles".

Mockito is unfortunately making the distinction weird.

A mock in mockito is a normal mock in other mocking frameworks (allows you to stub invocations; that is, return specific values out of method calls).

A spy in mockito is a partial mock in other mocking frameworks (part of the object will be mocked and part will use real method invocations).

You can enable verbose logging on your Mocked objects:

    import org.mockito.Mockito.mock;
    import org.mockito.Mockito.withSettings;

    List mockWithLogger = mock(List.class, withSettings().verboseLogging());

This should give you more information to understand the interactions.

https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/MockSettings.html#verboseLogging()