How to use findDeepAnnotation method of org.junit.experimental.theories.ParameterSignature class

You can also use AssertJ for fluent assertions

@Test
public void testThatOptionalIsNotEmpty() {
    assertThat(testedMethod()).isNotEmpty();
}

@Test
public void testThatOptionalHasValue() {
    assertThat(testedMethod()).hasValue("hello");
}

This appears to occur because only the source code is compiling when you use mvn clean compile (I'm using maven 3.1.0 so I'm not sure if it always behaved like this).

If you run mvn test, the test code will compile as well, but then it runs the tests (which may not be immediately desirable if you're trying to run them through Eclipse.) The way around this is to add test-compile to your Maven command sequence whenever you do a mvn clean. For example, you would run mvn clean compile test-compile.

JUnit 5 provides a way out of the box.

JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage

Each one is a distinct project and using all of them allows to compile and execute JUnit 4 and JUnit 5 tests in a same project.

JUnit Jupiter is the combination of the new programming model and extension model for writing tests and extensions in JUnit 5.

JUnit Vintage provides a TestEngine for running JUnit 3 and JUnit 4 based tests on the platform.

The JUnit Platform serves as a foundation for launching testing frameworks on the JVM

Update : from Maven Surefire 2.22.0

From the JUnit 5 documentation :

Starting with version 2.22.0, Maven Surefire provides native support for executing tests on the JUnit Platform.

So the configuration is much simpler.
Note that the junit-4 api dependency is optional as the engine dependencies that are now required already pull a default api version (it is the case for both junit 4 and 5).

Here is a sample pom.xml.

<project xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>david</groupId>
    <artifactId>jupiter-4-and-5-same-build</artifactId>
    <version>0.0.1-SNAPSHOT</version>

    <properties>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
        <junit-jupiter.version>5.1.0</junit-jupiter.version>
        <!-- optional : if we want to use a junit4 specific version -->
        <junit.version>4.12</junit.version>
    </properties>
    <dependencies>
        <!--JUnit Jupiter Engine to depend on the JUnit5 engine and JUnit 5 API -->
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter-engine</artifactId>
            <version>${junit-jupiter.version}</version>
            <scope>test</scope>
        </dependency>
        <!--JUnit Jupiter Engine to depend on the JUnit4 engine and JUnit 4 API  -->
        <dependency>
            <groupId>org.junit.vintage</groupId>
            <artifactId>junit-vintage-engine</artifactId>
            <version>${junit-jupiter.version}</version>
        </dependency>
        <!-- Optional : override the JUnit 4 API version provided by junit-vintage-engine -->
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>${junit.version}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.22.0</version>
            </plugin>
        </plugins>
    </build>

</project>

On my GitHub space I added a working sample maven project that you can browse/clone. URL: https://github.com/ebundy/junit4-and-5-minimal-maven-project

Old way : for Maven Surefire below 2.22.0

Here is the minimal configuration to use with Maven to configure the project to compile and run both JUnit4 and JUnit5 tests :

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>mygroup</groupId>
    <artifactId>minimal-conf-junit4-5</artifactId>
    <version>0.0.1-SNAPSHOT</version>

    <properties>
        <!-- JUnit 5 depends on JDK 1.8 -->
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
        <!--  JUnit dependency versions -->
        <junit.version>4.12</junit.version>
        <junit-vintage-engine>4.12.1</junit-vintage-engine>
        <junit-jupiter.version>5.0.1</junit-jupiter.version>
        <junit-platform.version>1.0.1</junit-platform.version>
    </properties>

    <dependencies>
        <!--JUnit Jupiter API to write and compile tests with JUnit5 -->
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter-api</artifactId>
            <version>${junit-jupiter.version}</version>
            <scope>test</scope>
        </dependency>
        <!-- JUnit 4 to make legacy JUnit 4 tests compile -->
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>${junit.version}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.19.1</version> <!-- matters until now-->
                <dependencies>
                    <!-- to let surefire to run JUnit 4 but also JUnit 5 tests -->
                    <dependency>
                        <groupId>org.junit.platform</groupId>
                        <artifactId>junit-platform-surefire-provider</artifactId>
                        <version>${junit-platform.version}</version>
                    </dependency>
                    <!-- JUnit vintage engine to run JUnit 3 or JUnit 4 tests -->
                    <dependency>
                        <groupId>org.junit.vintage</groupId>
                        <artifactId>junit-vintage-engine</artifactId>
                        <version>${junit-vintage-engine}</version>
                    </dependency>
                    <!-- JUnit 5 engine to run JUnit 5 tests -->
                    <dependency>
                        <groupId>org.junit.jupiter</groupId>
                        <artifactId>junit-jupiter-engine</artifactId>
                        <version>${junit-jupiter.version}</version>
                    </dependency>
                </dependencies>
            </plugin>
        </plugins>
    </build>
</project>

Now mvn test compiles and runs both JUnit 4 and JUnit 5 tests.

Note 1 : the junit-vintage-engine (4.12.1) and the junit (4.12) dependencies don't specify the same exact version.
This is not an issue at all as :

• their release are not related between them

• junit-vintage-engine is designed to run any JUnit 3 or 4 tests.
  

Note 2 : maven-surefire-plugin with the 2.19.1 version matters whatever you want to compile JUnit 5 test classes or both JUnit 4 and JUnit 5 test classes.
Next version of the plugin causes indeed some exceptions during JUnit 5 tests execution but the 2.22.0 that at last solves the issue (see the first part of the answer : "Update : from Maven Surefire 2.22.0").

This question is ancient, but Mockito v2.1.0+ now has a built-in feature for this.

verify(mock, description("This will print on failure")).someMethod("some arg");

More examples included from @Lambart's comment below:

verify(mock, times(10).description("This will print if the method isn't called 10 times")).someMethod("some arg");
verify(mock, never().description("This will print if someMethod is ever called")).someMethod("some arg");
verify(mock, atLeastOnce().description("This will print if someMethod is never called with any argument")).someMethod(anyString());

It's almost the exact same thing.

Recent versions of JUnit now include hamcrest.

In fact, org.junit.Assert.assertThat 's method signature is

public static <T> void assertThat(T actual,
                              org.hamcrest.Matcher<T> matcher)

which you will notice uses hamcrest matchers.

You may still want to include your own version of hamcrest because JUnit isn't updated very often and may not always use the latest version of hamcrest.

According to the maven pom, JUnit 4.11 uses hamcrest 1.3 which I believe is the most current as of this writing.

EDIT I've just read your second article http://blog.code-cop.org/2014/02/assert-or-matcherassert.html and it describes 2 slight differences in the hamcrest assertThat that make it more useful:

1. when the match fails, the error message includes what was different instead of "expected X but was Y". custom hamcrest matchers may include more detailed information about what exactly was wrong by implementing describeMismatch().
2. The assertThat signature is different in hamcrest using T actual, Matcher<? super T> matcher which allows matchers to be super types (like Matcher to compare Integers and Doubles). This usually doesn't matter but when you need it this is a nice feature to have.

So use org.hamcrest.MatcherAssert.assertThat.

Answer was right in front of me in the copy-dependencies mojo docs (I even linked to it). The documentation for the property includes the Expression you can refer to it by.

useRepositoryLayout: Place each artifact in the same directory layout as a default repository. example: /outputDirectory/junit/junit/3.8.1/junit-3.8.1.jar

* Type: boolean
* Since: 2.0-alpha-2
* Required: No
* Expression: ${mdep.useRepositoryLayout}
* Default: false

To set this property from command line you need to run

mvn -Dmdep.useRepositoryLayout=true <goals go here>

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()

Firstly, application.properties in the @PropertySource should read application-test.properties if that's what the file is named (matching these things up matters):

@PropertySource("classpath:application-test.properties ")

That file should be under your /src/test/resources classpath (at the root).

I don't understand why you'd specify a dependency hard coded to a file called application-test.properties. Is that component only to be used in the test environment?

The normal thing to do is to have property files with the same name on different classpaths. You load one or the other depending on whether you are running your tests or not.

In a typically laid out application, you'd have:

src/test/resources/application.properties

and

src/main/resources/application.properties

And then inject it like this:

@PropertySource("classpath:application.properties")

The even better thing to do would be to expose that property file as a bean in your spring context and then inject that bean into any component that needs it. This way your code is not littered with references to application.properties and you can use anything you want as a source of properties. Here's an example: how to read properties file in spring project?

Take a look at the readme which describes how to add additional paths.

By default, intellij-protobuf-editor uses the project's configured source roots as protobuf import paths. If this isn't correct, you can override these paths in Settings > Languages & Frameworks > Protocol Buffers. Uncheck "Configure automatically" and add whichever paths you need. In your case, you'd add .../src/main/java/proto (where ... means whatever your project's base path is).