How to use StringContains class of org.hamcrest.core package

I had a bean annotated with @Singleton and @Stateless that triggered this error. My code was of course wrong but the message and posts like this lead me down the wrong path for a while.

Well mockito mocks works by extending the class and overriding the method, which in your case is not possible on A.a(String). If you want this to happen you have to remove the final modifier.

Now assuming A.a(String) is not final, what you ask is completely doable with mockito:

given(mockA.a(anyString()).willAnswer(returnOfB(bInstance));

Answer<String> returnOfB(final B bInstance) {
    return new Answer<String>() {
         public String answer(Invocation invocation) {
             String arg = (String) invocation.getActualArguments()[0];
             return bInstance.b(arg);
         }
    };
}

Please note this answer has been written on a phone and might have typo, or wrong names, though you should get the idea of what should be done to achieve what you want.

Cheers

You could use a pattern as well, for example

 mvn '-Dtest=de.mypackage.*Test' test

runs all tests in classes from package de.mypackage ending on *Test.

[update 2017/12/18]:
Since this became the accepted answer, here's some further information:

• Maven uses the Maven Surefire plugin to execute tests.

• The syntax used above (qualified package name) requires Surefire version 2.19.1 or higher! Earlier versions require the use of path expressions, for example

  mvn -Dtest="de/mypackage/*Test" test
  

• I'm using quotes (` or ") to prevent the shell from performing pathname expansion, Maven doesn't require any quotes.

• A single test method can be exuted using the following syntax

  mvn -Dtest=MyUnitTest#testMethod test
  

• All tests from subpackages may be includes as well, in order to execute all tests in or beneath package de.mypackage.sub execute:

  mvn -Dtest="de/mypackage/sub/**" test
  

  or with Surefire 2.19.1 or higher

  mvn -Dtest="de.mypackage.sub.**" test
  

There are further possibilities like using regular expressions, see the official documentation of running a single test.

Files from src/main/resources will be available on the classpath during runtime of the main program, while files both from src/main/resources and src/test/resources will be available on the classpath during test runs.

One way to retrieve files residing on the classpath is:

Object content = Thread.currentThread().getContextClassLoader().getResource("file.dat").getContent();

.. where the type of content depends on the file contents. You can also get the file as an InputStream:

InputStream contentStream = Thread.currentThread().getContextClassLoader().getResourceAsStream("file.dat");

You can accomplish this with JUnit's ParallelComputer (note it's still considered experimental). It's a pretty simple implementation which is backed by the java.util.concurrent.ExecutorService API.
If you're curious how it works, check out the source.

Basically you call JUnitCore.runClasses(Computer, Classes ...) and pass in a ParallelComputer object for the first argument.

Example usage:

import org.junit.Test;
import org.junit.experimental.ParallelComputer;
import org.junit.runner.JUnitCore;

public class ParallelComputerExample {

    @Test
    public void runAllTests() {
        Class<?>[] classes = { ParallelTest1.class, ParallelTest2.class };

        // ParallelComputer(true,true) will run all classes and methods 
        // in parallel.  (First arg for classes, second arg for methods)
        JUnitCore.runClasses(new ParallelComputer(true, true), classes);
    }

    public static class ParallelTest1 {
        @Test
        public void test1a() {
            lookBusy(3000);
        }

        @Test
        public void test1b() {
            lookBusy(3000);
        }
    }

    public static class ParallelTest2 {
        @Test
        public void test2a() {
            lookBusy(3000);
        }

        @Test
        public void test2b() {
            lookBusy(3000);
        }
    }

    public static void lookBusy(long ms) {
        try {
            Thread.sleep(ms);
        } catch (InterruptedException e) {
            System.out.println("interrupted");
        }
    }
}

The above code will run in 3 seconds because all methods and classes are ran in parallel.

This will run in 6s (because all classes are in parallel). JUnitCore.runClasses(new ParallelComputer(true, false), classes);

This will also run in 6s (because all methods are in parallel). JUnitCore.runClasses(new ParallelComputer(false, true), classes);

VisualVM is included in the most recent releases of Java. You can use this to create a heap dump, and look at the objects in it.

Alternatively, you can also create a heapdump commandine using jmap (in your jdk/bin dir):

jmap -dump:format=b,file=heap.bin <pid>

You can even use this to get a quick histogram of all objects

jmap -histo <pid>

I can recommend Eclipse Memory Analyzer (http://eclipse.org/mat) for advanced analysis of heap dumps. It lets you find out exactly why a certain object or set of objects is alive. Here's a blog entry showing you what Memory Analyzer can do: http://dev.eclipse.org/blogs/memoryanalyzer/2008/05/27/automated-heap-dump-analysis-finding-memory-leaks-with-one-click/

The official junit solution to assert that two BigDecimal are matematically equal is to use hamcrest.

With java-hamcrest 2.0.0.0 we can use this syntax:

    // import static org.hamcrest.MatcherAssert.assertThat;
    // import org.hamcrest.Matchers;

    BigDecimal a = new BigDecimal("100")
    BigDecimal b = new BigDecimal("100.00")
    assertThat(a,  Matchers.comparesEqualTo(b));

Hamcrest 1.3 Quick Reference

Spring provides a class called MockHttpServletRequest, which can be used to test code that needs a HttpServletRequest.

public void testCheckBatchExecutionSchedule() throws Exception
{
   MockHttpServletRequest request = new MockHttpServletRequest();
   request.addParameter("parameterName", "someValue");
   assertTrue("Batch is Completed :", returnPointsRatingDisputeFrom.checkBatchExecutionSchedule(request));
}

The best solution for this is to create a simple parent pom file project (with packaging 'pom') generically for all projects from your organization.

<?xml version="1.0" encoding="UTF-8"?>
<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/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>your.company</groupId>
    <artifactId>company-parent</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <distributionManagement>
        <repository>
            <id>nexus-site</id>
            <url>http://central_nexus/server</url>
        </repository>
    </distributionManagement>

</project>

This can be built, released, and deployed to your local nexus so everyone has access to its artifact.

Now for all projects which you wish to use it, simply include this section:

<parent>
  <groupId>your.company</groupId>
  <artifactId>company-parent</artifactId>
  <version>1.0.0</version>
</parent>

This solution will allow you to easily add other common things to all your company's projects. For instance if you wanted to standardize your JUnit usage to a specific version, this would be the perfect place for that.

If you have projects that use multi-module structures that have their own parent, Maven also supports chaining inheritance so it is perfectly acceptable to make your project's parent pom file refer to your company's parent pom and have the project's child modules not even aware of your company's parent.

I see from your example project structure that you are attempting to put your parent project at the same level as your aggregator pom. If your project needs its own parent, the best approach I have found is to include the parent at the same level as the rest of the modules and have your aggregator pom.xml file at the root of where all your modules' directories exist.

- pom.xml (aggregator)
    - project-parent
    - project-module1
    - project-module2

What you do with this structure is include your parent module in the aggregator and build everything with a mvn install from the root directory.

We use this exact solution at my organization and it has stood the test of time and worked quite well for us.