How to use ParameterSupplier class of org.junit.experimental.theories package

You can use MockingDetails and either printInvocations or getInvocations to inspect the interactions belonging to a mock. However, this will not produce a list of invocations belonging to multiple mocks in the order that happened: just interactions with each individual mock.

Code snippet, as contributed by elhefe and Anand Rockzz:

import static org.mockito.Mockito.mockingDetails;

System.out.println(mockingDetails(mock).printInvocations());
/* or */
System.out.println(mockingDetails(mock).getInvocations());

Acknowledging your reluctance and caveats in the comments, I would say that this is a technique that does more to lock in your current implementation than to analyze your real constraints and prevent regressions. Furthermore, if your algorithm has a lot of interactions with direct collaborators, that might be an indication that the algorithm should be refactored.

If the system is untested or undocumented legacy code, this might be a practical way to programmatically generate a regression test or analysis--a temporary starting point for more-informed regression testing--but in your shoes I would instead start by documenting the contract of each component and then writing a test that confirms those interactions and constraints. Mockito recommendations (as intimated through this article by Mockito's original developer) tend toward adding stubs until tests pass and adding verifications/counts only where there are expensive or non-idempotent side effects.

You should use RuntimeException or subclass it. Your method has to declare checked exception (example: findByState(String state) throws IOException;) otherwise use RuntimeException:

 when(userRepository.findByState("Karnataka"))
       .thenThrow(new RuntimeException("Exception"));

You can use SpringClassRule and SpringMethodRule - supplied with Spring

import org.junit.ClassRule;
import org.junit.Rule;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.springframework.test.context.junit4.rules.SpringClassRule;
import org.springframework.test.context.junit4.rules.SpringMethodRule;

@RunWith(Parameterized.class)
@ContextConfiguration(...)
public class MyTest {

    @ClassRule
    public static final SpringClassRule SPRING_CLASS_RULE = new SpringClassRule();

    @Rule
    public final SpringMethodRule springMethodRule = new SpringMethodRule();

    ...

In case anyone stumbles upon this question and wants to see how to get Guice annotations working from unit tests, extend your tests from a base class like the one below and call injector.injectMembers(this);

public class TestBase {
    protected Injector injector = Guice.createInjector(new AbstractModule() {
        @Override
        protected void configure() {
            bind(HelloService.class);
        }
    });

    @Before
    public void setup () {
        injector.injectMembers(this);
    }
}

Then your test can get an injected HelloService like this

public class HelloServiceTest extends TestBase {
    @Inject
    HelloService service;

    @Test
    public void testService() throws Exception {
       //Do testing here
    }
}

It seems like you're having the JAVA_HOME set in your mvn.bat. It could be pointing to the older version of Java (i.e., 8 in your case).

set JAVA_HOME=C:\path\to\jdk11. Try using it on the first line, before calling Maven.

All these answers seem overkill.
You don't add tests to make a metric tool happy.
Loading a Spring context of the application takes time. Don't add it in each developer build just to win about 0.1% of coverage in your application.
Here you don't cover only 1 statement from 1 public method. It represents nothing in terms of coverage in an application where thousands of statements are generally written.

First workaround : make your Spring Boot application class with no bean declared inside. If you have them, move them in a configuration class (for make them still cover by unit test). And then ignore your Spring Boot application class in the test coverage configuration.

Second workaround : if you really need to to cover the main() invocation (for organizational reasons for example), create a test for it but an integration test (executed by an continuous integration tool and not in each developer build) and document clearly the test class purpose :

import org.junit.Test;

// Test class added ONLY to cover main() invocation not covered by application tests.
public class MyApplicationIT {
   @Test
   public void main() {
      MyApplication.main(new String[] {});
   }
}

An alternative to ArgumentMatcher is ArgumentCaptor.

Official example:

ArgumentCaptor<Person> argument = ArgumentCaptor.forClass(Person.class);
verify(mock).doSomething(argument.capture());
assertEquals("John", argument.getValue().getName());

A captor can also be defined using the @Captor annotation:

@Captor ArgumentCaptor<Person> captor;
//... MockitoAnnotations.initMocks(this);
@Test public void test() {
    //...
    verify(mock).doSomething(captor.capture());
    assertEquals("John", captor.getValue().getName());
}

In IntelliJ it works as follows: Go to configurations -> VM options and add the parameter/value pair:

-DmyParameter=value

Make sure you add a "D" after the "-"!

Does this mean, that Test Suites are considered deprecated now, or is the same concept still available under another name?

Bitter Suite Answer:

There is in fact support for test suites in JUnit 5, but it's almost certainly not what you're looking for. However, the JUnit Team is working on something that will likely suit your needs.

Detailed Answer:

As of JUnit 5.2, the only built-in support for suites is via the JUnitPlatform Runner (registered via @RunWith(JUnitPlatform.class)). That runner actually launches the JUnit Platform (a.k.a., JUnit 5 infrastructure) and allows you to execute tests against various programming models such as JUnit 4 and JUnit Jupiter. It also allows you to select various things (e.g., classes, packages, etc.) and configure include and exclude filters (e.g., for tags or test engines).

The problem with the runner is that it can not be executed directly on the JUnit Platform. It can only be executed using JUnit 4 by itself. That means that you lose the full reporting capabilities of the JUnit Platform since information is lost in translation from the JUnit Platform to JUnit 4.

In summary, you can technically use the JUnitPlatform runner to execute a suite using JUnit 5, and the tests will execute, but the reporting and display in an IDE will be suboptimal.

On the bright side, the JUnit Team plans to provide built-in support for suites in JUnit 5 that does not suffer from the shortcomings of the JUnitPlatform runner for JUnit 4. For details, see all issues assigned to the "suites" label on GitHub.

In addition, there is already a feature branch that you can check out which can be consumed in a Maven or Gradle build via JitPack.

Regards,

Sam (JUnit 5 core committer)