How to use appendValueList method of org.hamcrest.Interface Description class

I'm not quite getting the specifics of your scenario, but here's how I generally test for expected failure:

The slick new way:

@Test(expected=NullPointerException.class)
public void expectedFailure() {
    Object o = null;
    o.toString();
}

for older versions of JUnit:

public void testExpectedFailure() {
    try {
        Object o = null;
        o.toString();
        fail("shouldn't get here");
    }
    catch (NullPointerException e) {
        // expected
    }
}

If you have a bunch of things that you want to ensure throw an exception, you may also want to use this second technique inside a loop rather than creating a separate test method for each case. If you were just to loop through a bunch of cases in a single method using expected, the first one to throw an exception would end the test, and the subsequent cases wouldn't get checked.

You should not access test classes from your application code, but rather create a main (the same main) in the test scope and create an additional artifact for your project.

However, in this additional artifact (jar) you would need to have:

• The test classes
• The application code classes
• External dependencies required by application code (in compile scope)
• External dependencies required by the test code (in test scope)

Which basically means a fat jar with the addition of test classes (and their dependencies). The Maven Jar Plugin and its test-jar goal would not suit this need. The Maven Shade Plugin and its shadeTestJar option would not help neither.

So, how to create in Maven a fat jar with test classes and external dependencies?

The Maven Assembly Plugin is a perfect candidate in this case.

Here is a minimal POM sample:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.sample</groupId>
    <artifactId>sample-project</artifactId>
    <version>1.0-SNAPSHOT</version>

    <build>
        <plugins>
            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <version>2.3</version>
                <configuration>
                    <descriptor>src/main/assembly/assembly.xml</descriptor>
                </configuration>
                <executions>
                    <execution>
                        <id>make-assembly</id>
                        <phase>package</phase>
                        <goals>
                            <goal>single</goal>
                        </goals>
                        <configuration>
                            <archive>
                                <manifest>
                                    <mainClass>com.sample.TestMain</mainClass>
                                </manifest>
                            </archive>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.11</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

The configuration above is setting the main class defined by you in your test classes. But that's not enough.

You also need to create a descriptor file, in the src\main\assembly folder an assembly.xml file with the following content:

<assembly
    xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.3"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.3 http://maven.apache.org/xsd/assembly-1.1.3.xsd">
    <id>fat-tests</id>
    <formats>
        <format>jar</format>
    </formats>
    <includeBaseDirectory>false</includeBaseDirectory>
    <dependencySets>
        <dependencySet>
            <outputDirectory>/</outputDirectory>
            <useProjectArtifact>true</useProjectArtifact>
            <unpack>true</unpack>
            <scope>test</scope>
        </dependencySet>
    </dependencySets>
    <fileSets>
        <fileSet>
            <directory>${project.build.directory}/test-classes</directory>
            <outputDirectory>/</outputDirectory>
            <includes>
                <include>**/*.class</include>
            </includes>
            <useDefaultExcludes>true</useDefaultExcludes>
        </fileSet>
    </fileSets>
</assembly>

The configuration above is:

• setting external dependencies to be taken from the test scope (which will also take the compile scope as well)
• setting a fileset to include compiled test classes as part of the packaged fat jar
• setting a final jar with fat-tests classifier (hence your final file will be something like sampleproject-1.0-SNAPSHOT-fat-tests.jar).

You can then invoke the main as following (from the target folder):

java -jar sampleproject-1.0-SNAPSHOT-fat-tests.jar

From such a main, you could also invoke all of your test cases as following:

• Create a JUnit test suite
• Add to the test suite the concerned tests
• Invoke the test suite from your plain Java main

Example of test suite:

import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;

@RunWith(Suite.class)
@SuiteClasses({ AppTest.class })
public class AllTests {

}

Note: in this case the test suite is only concerning the AppTest sample test.

Then you could have a main class as following:

import org.junit.internal.TextListener;
import org.junit.runner.JUnitCore;

public class MainAppTest {

    public static void main(String[] args) {
        System.out.println("Running tests!");
        
        JUnitCore engine = new JUnitCore();
        engine.addListener(new TextListener(System.out)); // required to print reports
        engine.run(AllTests.class);
    }
}

The main above would then execute the test suite which will in chain execute all of the configured tests.

You really want the test to do one thing, and to test for that. If you're not sure as to which exception is going to be thrown, that doesn't sound like a good test to me.

e.g. (in pseudo-code)

try {
   badOperation();
   /// looks like we succeeded. Not good! Fail the test
   fail();
}
catch (ExpectedException e) {
   // that's fine
}
catch (UnexpectedException e) {
   // that's NOT fine. Fail the test
}

so if you want to test that your method throws 2 different exceptions (for 2 sets of inputs), then you'll need 2 tests.

ConfigurationManagerTest is not being found on your classpath. Ensure that the ConfigurationManagerTest.class file is available on your classpath.

It might not exist if it wasn't successfully compiled or if it's being created in a directory that you haven't told the Eclipse project should be on the classpath.

Assuming that you've put your test classes in a separate folder, make sure that it shows up in the "Package Explorer" view (rather than the "Navigator" view).

Under the project properties, "Java Build Path" and the "Source" tab, you can also see if the source folder is included for building as well as where the .class files are generated.

There was a request in the comments for a Spring 3 example on how to do this.

<bean id="systemPrereqs"
    class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
    <property name="targetObject" value="#{@systemProperties}" />
    <property name="targetMethod" value="putAll" />
    <property name="arguments">
        <!-- The new Properties -->
        <util:properties>
            <prop key="java.security.auth.login.config">/super/secret/jaas.conf</prop>
        </util:properties>
    </property>
</bean>

As of JUnit 5.8.0, there is a Named<T> interface as part of the JUnit Jupiter API with "automatic support for injecting the contained payload [the arguments] into parameterized methods directly" (see issue #2301). Example:

@DisplayName("A parameterized test with named arguments")
@ParameterizedTest
@MethodSource("namedArguments")
void testWithNamedArguments(File file) {}

static Stream<Arguments> namedArguments() {
    return Stream.of(
        Arguments.of(Named.of("An important file", new File("path1"))),
        Arguments.of(Named.of("Another file", new File("path2")))
    );
}

If you prefer static imports, you can also go for the corresponding aliases from Arguments and Named:

arguments(named("An important file", new File("path1")))

For more information, please refer to the corresponding docs.

Here is what I have and it runs just fine.

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;

@RunWith(Suite.class)
@SuiteClasses({ TestSuite1.class, TestSuite2.class })
public class CompleteTestSuite {

    @BeforeClass 
    public static void setUpClass() {      
        System.out.println("Master setup");

    }

    @AfterClass public static void tearDownClass() { 
        System.out.println("Master tearDown");
    }

}

Here is my test suite 1 (do the same for test suite 2).

import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;

@RunWith(value = Suite.class)
@SuiteClasses(value = { TestCase1.class })
public class TestSuite1 {}

And here is my test class. Create both testcase1 and testcase2.

import static org.junit.Assert.assertEquals;

import org.junit.BeforeClass;
import org.junit.Test;

public class TestCase1 {

    @BeforeClass 
    public static void setUpClass() {      
        System.out.println("TestCase1 setup");
    }

    @Test
    public void test1() {
        assertEquals(2 , 2);
    }
}    

you should have 5 classes completesuite suite1 suite2 test1 test2

and make sure you have Junit in your build path. This should run!

Here is the output

Master setup
TestCase1 setup
Master tearDown

They both achieve the same result. Using an annotation (@Mock) is usually considered "cleaner", as you don't fill up your code with boilerplate assignments that all look the same.

Note that in order to use the @Mock annotation, your test class should be annotated with @RunWith(MockitoJUnitRunner.class) or contain a call to MockitoAnnotations.initMocks(this) in its @Before method.

The Maven build lifecycle now includes the "integration-test" phase for running integration tests, which are run separately from the unit tests run during the "test" phase. It runs after "package", so if you run "mvn verify", "mvn install", or "mvn deploy", integration tests will be run along the way.

By default, integration-test runs test classes named **/IT*.java, **/*IT.java, and **/*ITCase.java, but this can be configured.

For details on how to wire this all up, see the Failsafe plugin, the Failsafe usage page (not correctly linked from the previous page as I write this), and also check out this Sonatype blog post.