How to use describeMismatch method of org.hamcrest.Interface Matcher class

I've used JUnit for doing a lot of integration testing. Integration testing can, of course, mean many different things. For more system level integration tests, I prefer to let scripts drive my testing process from outside.

Here's an approach that works well for me for applications that use http and databases and I want to verify the whole stack:

1. Use Hypersonic or H2 in in-memory mode as a replacement for the database (this works best for ORMs)
2. Initialize the database in @BeforeSuite or equivalent (again: easiest with ORMs)
3. Use Jetty to start an in-process web server.
4. @Before each test, clear the database and initialize with the necessary data
5. Use JWebUnit to execute HTTP requests towards Jetty

This gives you integration tests that can run without any setup of database or application server and that exercises the stack from http down. Since it has no dependencies on external resources, this test runs fine on the build server.

Here some of the code I use:

@BeforeClass
public static void startServer() throws Exception {
    System.setProperty("hibernate.hbm2ddl.auto", "create");
    System.setProperty("hibernate.dialect", "...");
    DriverManagerDataSource dataSource = new DriverManagerDataSource();
    dataSource.setJdbcUrl("jdbc:hsqldb:mem:mytest");
    new org.mortbay.jetty.plus.naming.Resource(
             "jdbc/primaryDs", dataSource);


    Server server = new Server(0);
    WebAppContext webAppContext = new WebAppContext("src/main/webapp", "/");
    server.addHandler(webAppContext);
    server.start();
    webServerPort = server.getConnectors()[0].getLocalPort();
}

// From JWebUnit
private WebTestCase tester = new WebTestCase();

@Before
public void createTestContext() {
    tester.getTestContext().setBaseUrl("http://localhost:" + webServerPort + "/");
    dao.deleteAll(dao.find(Product.class));
    dao.flushChanges();
}

@Test
public void createNewProduct() throws Exception {
    String productName = uniqueName("product");
    int price = 54222;

    tester.beginAt("/products/new.html");
    tester.setTextField("productName", productName);
    tester.setTextField("price", Integer.toString(price));
    tester.submit("Create");

    Collection<Product> products = dao.find(Product.class);
    assertEquals(1, products.size());
    Product product = products.iterator().next();
    assertEquals(productName, product.getProductName());
    assertEquals(price, product.getPrice());
}

For those who'd like to know more, I've written an article about Embedded Integration Tests with Jetty and JWebUnit on Java.net.

Take a look at my question here:

You can specify a location on the classpath by setting the feature attribute in the options annotation like

@Cucumber.Options(features="src/test/resources")

Edit:

in new versions code is

@CucumberOptions(features="src/test/resources")

@TestInstance(PER_CLASS)

You may select the "single test instance per class" mode annotating the nested class with @TestInstance(TestInstance.Lifecycle.PER_CLASS):

class ColorTest {

    @Nested
    @TestInstance(TestInstance.Lifecycle.PER_CLASS)
    class Inner {

        @ParameterizedTest
        @MethodSource("colors")
        void blue(Color color, int blue) {
            Assertions.assertEquals(color.getBlue(), blue);
        }

        Stream<Arguments> colors() {
            return Stream.of(
                    Arguments.of(Color.BLACK, 0),
                    Arguments.of(Color.GRAY, 128),
                    Arguments.of(Color.BLUE, 255)
            );
        }
    }

}

When using this mode, a new test instance will be created once per test class.

ArgumentsProvider

Or you may switch from a MethodSource to an ArgumentsProvider.

I modified your example to see if it compiles and runs locally:

class ColorTest {

    static class Blues implements ArgumentsProvider {

        @Override
        public Stream<Arguments> provideArguments(ExtensionContext context) {
            return Stream.of(
                    Arguments.of(Color.BLACK, 0),
                    Arguments.of(Color.GRAY, 128),
                    Arguments.of(Color.BLUE, 255)
            );
        }
    }

    @Nested
    class Inner {

        @ParameterizedTest
        @ArgumentsSource(Blues.class)
        void blue(Color color, int blue) {
            Assertions.assertEquals(color.getBlue(), blue);
        }
    }

}

More details at http://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests

Adding specific dependencies solve the problem.

NOTE: UPDATE INTELLIJ ABOVE 2017.2.0 AS THERE WAS A BUG WITH THE JUNIT LAUNCHER

OXYGEN if you using eclipse.

---

Below dependency enables Junit5 parametrized tests which can be used instead of a DataProvider.

"org.junit.jupiter:junit-jupiter-params:5.0.0"
//for JUnit5 parametrized tests.

---

Junit5 API.

"org.junit.jupiter:junit-jupiter-api:5.0.0"
//JUnit5 API

---

Needed if you want to run legacy JUnit4 tests without changing the syntax and imports.

"org.junit.vintage:junit-vintage-engine:4:12.0"
//for legacy JUnit4 tests

EDIT: 07/2018 Match the version of the vintage runner to the jupiter version

---

Needed if you want to run JUnit5 tests with new syntax and imports.

"org.junit.jupiter:junit-jupiter-engine:5.0.0"
//for JUnit5 tests

java.lang.NoSuchMethodError: org.junit.platform.engine.EngineDiscoveryRequest.getDiscoveryFiltersByType(Ljava/lang/Class;)Ljava/util/List;

---

Launcher.

"org.junit.platform:junit-platform-launcher:1.0.0
//to handle default launcher

Exception in thread "main" java.lang.NoSuchMethodError: org.junit.platform.commons.util.ReflectionUtils.getDefaultClassLoader()Ljava/lang/ClassLoader;

---

Additional info how to install JUnit5

---

Since version 4.6 for Gradle, there is no need for plugins anymore Gradle supports Junit5 natively just do: And the version of the vintage runner is now same as the JUnit 5 version.

dependencies {

    testImplementation "org.junit.jupiter:junit-jupiter-params:$junitVersion"
    testImplementation "org.junit.jupiter:junit-jupiter-api:$junitVersion"

    testRuntimeOnly "org.junit.vintage:junit-vintage-engine:$junitVersion"
    testRuntimeOnly "org.junit.jupiter:junit-jupiter-engine:$junitVersion"
}

test {  
    useJUnitPlatform {
        includeEngines 'junit-jupiter', 'junit-vintage'
    }
}

Another option is to use maven-dependency-plugin. You can copy all dependent libraries to a folder such as lib, and use that for classpath.

In order to copy dependencies:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <executions>
        <execution>
            <id>copy</id>
            <phase>package</phase>
            <goals>
                <goal>copy-dependencies</goal>
            </goals>
            <configuration>
                <outputDirectory>
                    ${project.build.directory}/lib
                </outputDirectory>
            </configuration>
        </execution>
    </executions>
</plugin>

and for the classpath, here classpathPrefix specifies that all dependencies should be located in a "lib" folder relative to the archive.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <version>2.3.2</version>
    <configuration>
        <archive>
            <manifest>
                <addClasspath>true</addClasspath>
                <classpathPrefix>lib/</classpathPrefix>
                <mainClass>com.citusdata.hadoop.HadoopTest</mainClass>
            </manifest>
        </archive>
    </configuration>
</plugin>

For further information:

http://www.ibm.com/developerworks/java/library/j-5things13/index.html http://maven.apache.org/plugins/maven-dependency-plugin/usage.html

Use a ByteArrayOutputStream and then get the data out of that using toByteArray(). This won't test how it writes to the stream (one byte at a time or as a big buffer) but usually you shouldn't care about that anyway.

Coworkers of mine at our company wrote a freely available DataProvider in TestNG style for JUnit which you can find on github (https://github.com/TNG/junit-dataprovider).

We use it in very large projects and it works just fine for us. It has some advantages over JUnit's Parameterized as it will reduce the overhead of separate classes and you can execute single tests as well.

An example looks something like this

@DataProvider
public static Object[][] provideStringAndExpectedLength() {
    return new Object[][] {
        { "Hello World", 11 },
        { "Foo", 3 }
    };
}

@Test
@UseDataProvider( "provideStringAndExpectedLength" )
public void testCalculateLength( String input, int expectedLength ) {
    assertThat( calculateLength( input ) ).isEqualTo( expectedLength );
}

Edit: Since v1.7, it also supports other ways to provide data (strings, lists) and can inline the provider so that a separate method is not necessarily needed.

A full, working example can be found on the manual page on github. It also has a few more features, like collecting the providers in utility classes and accessing them from other classes etc. The manual page is very detailed, I'm sure you'll find any questions answered there.

I had the same problem in my unit tests. I didn't realize the Base64 class I'm using is a part of the Android API, therefore

You can't use android.util.Base64 in a regular JUnit test, it must be an Instrumentation test.

However, if you really want it as a unit test, you could use the Apache Commons Base64 class instead. Include it in Gradle build:

// https://mvnrepository.com/artifact/org.apache.commons/commons-collections4
compile group: 'org.apache.commons', name: 'commons-collections4', version: '4.1'

And then slightly different usage,

• Base64.encodeBase64String(byte[] binaryData)

• Base64.decodeBase64(String base64String)

IMHO Reflection should really only be a last resort, reserved for the special case of unit testing legacy code or an API you can't change. If you are testing your own code, the fact that you need to use Reflection means your design is not testable, so you should fix that instead of resorting to Reflection.

If you need to access private members in your unit tests, it usually means the class in question has an unsuitable interface, and/or tries to do too much. So either its interface should be revised, or some code should be extracted into a separate class, where those problematic methods / field accessors can be made public.

Note that using Reflection in general results in code which, apart from being harder to understand and maintain, is also more fragile. There are a whole set of errors which in the normal case would be detected by the compiler, but with Reflection they crop up as runtime exceptions only.

Update: as @tackline noted, this concerns only using Reflection within one's own test code, not the internals of the testing framework. JUnit (and probably all other similar frameworks) uses reflection to identify and call your test methods - this is a justified and localized use of reflection. It would be difficult or impossible to provide the same features and convenience without using Reflection. OTOH it is completely encapsulated within the framework implementation, so it does not complicate or compromise our own testing code.