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

Well there's always

assertThat(list.isEmpty(), is(false));

... but I'm guessing that's not quite what you meant :)

Alternatively:

assertThat((Collection)list, is(not(empty())));

empty() is a static in the Matchers class. Note the need to cast the list to Collection, thanks to Hamcrest 1.2's wonky generics.

The following imports can be used with hamcrest 1.3

import static org.hamcrest.Matchers.empty;
import static org.hamcrest.core.Is.is;
import static org.hamcrest.core.IsNot.*;

To get thing rolling you need to add the following to the gradle file:

task copyTestResources(type: Copy) {
    from "${projectDir}/src/test/resources"
    into "${buildDir}/classes/test"
}
processTestResources.dependsOn copyTestResources

What it basically does is copying all the files in the src/test/resource directory to build/classes/test, since this.getClass().getClassLoader().getResourceAsStream(".") points to build/classes/test.

The issue is already known to Google and they want to fix it in Android Studio 1.2 (since they need IntelliJ14 for that and it seems like it will be included in Android Studio 1.2)

The error is in the stack trace

Could not autowire field: private javax.servlet.http.HttpServletRequest com.myapp.controller.ProductController.request; ... No matching bean of type [javax.servlet.http.HttpServletRequest]

The problem is that simple Spring tests run with the bare Spring apprlication context, without Spring Web Application context capabilities. So HttpServletRequests, Servlet Context and other features are not available in this case.

Try adding @WebAppConfiguration annotation to the test class.

Please note, that this option is available only in Spring 3.2+ versions.

In the older versions of Spring you'll need to invent something to make this interface implementations available in the application context(the most straightforward thing is to expose MockServletContext class and/or HttpServletRequest interface as beans for tests).

Also please note that the code that uses session scope beans is usually controller specific and belongs to web application context and I believe that it will be the best practice to test controllers in separate tests with the @WebAppConfiguration, but leave the tests of the plain old beans and services belonging to the root application context in the simple application contexts, i.e. without @WebAppConfiguration.

Just to be clear ProductDAO belongs to the root application context, and ProductController belongs to the web application context, so their definitions should be placed in different xml files. ProductDAO test should point to the xml of the root app context only and contain no @WebAppConfiguration.

As for ProductController test should point to both root app context and web app context xml files (see How to Setup web application context in Spring MVC test for examples) and be annotated with @WebAppConfiguration

You can use Hamcrest matchers to get a clearer error message here:

int i = 2;
assertThat(i, Matchers.either(Matchers.is(3)).or(Matchers.is(5))

or

int i = 2;
assertThat(i, Matchers.anyOf(Matchers.is(3),Matchers.is(5)));

This will more clearly explain:

Expected: (is <3> or is <5>)
     but: was <2>

showing exactly the expectation and the incorrect value that was provided.

(Slight disclaimer, I've never done this personally, just read about it in the javadoc)... If all of your methods on your mock interface would be ok with the same default behaviour, you could set the default answer on your mock in a manner like:

Foo myMock = Mockito.mock(Foo.class,new ThrowsExceptionClass(IllegalArgumentException.class));
Mockito.when(myMock.doSomething(Matchers.eq("1"))).thenReturn("1");

JavaDoc Links for: Mockito#mock and ThrowsExceptionClass

Alternatively, as is discussed in the Stubbing tutorial, order of the stubbing matters and last matching wins, so you might be able to also do:

Foo myMock = Mockito.mock(Foo.class);
Mockito.when(myMock.doSomething(Matchers.any(String.class))).thenThrow(IllegalArgumentException.class);
Mockito.when(myMock.doSomething(Matchers.eq("1"))).thenReturn("1");

You are using the @InjectMocks for constructor incjection. This will work as long as Mockito finds the field not initalized (null). JUnit is creating a new instance of the test class before each test, so JUnit fans (like me) will never face such problem. TestNg is not creating a new instance of test class. It's keeping the state between test methods, so when MockitoAnnotations.initMocks(this) is called for the second time, Mockito will find subject field already initialized and will try to use field injection. This on the other turn will work until the field is not final.

Is this is a bug? I believe not - rather a natural consequence of the API design. Some workaround for you would be to add

this.subject = null;

in some @AfterMethod method.

How do I add a junit 4 dependency correctly?

Assuming you're resolving against a standard Maven (or equivalent) repo:

dependencies {
    ...
    testCompile "junit:junit:4.11"  // Or whatever version
}

Run those tests in the folders of tests/model?

You define your test source set the same way:

sourceSets {
    ...

    test {
        java {
            srcDirs = ["test/model"]  // Note @Peter's comment below
        }
    }
}

Then invoke the tests as:

./gradlew test

EDIT: If you are using JUnit 5 instead, there are more steps to complete, you should follow this tutorial.

One way is using reflection get rid of final modifier from the field and then replace the LOGGER field with Mocked one

public class Class1Test {
    @Test
    public void test() throws Exception {
        Logger logger = Mockito.mock(Logger.class);
        Mockito.when(logger.isInfoEnabled()).thenReturn(false);
        setFinalStatic(Class1.class.getDeclaredField("LOGGER"), logger);
        Class1 cls1 = new Class1();
        assertFalse(cls1.demoMethod());
    }

    static void setFinalStatic(Field field, Object newValue) throws Exception {
        field.setAccessible(true);        
        Field modifiersField = Field.class.getDeclaredField("modifiers");
        modifiersField.setAccessible(true);
        modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL);
        field.set(null, newValue);
    }
}

How to see the real benefits of the approach described in the book?

The purpose of separate instance is not for any benefit but to maintain the contract that each test should be independently executed without any effect of the execution of a previous test. There is just no other way to ensure this contract other than using a different instance for each test.

For example, the Spring transaction management makes sure to rollback all changes made to the database by a test, by default, to maintain the same contract.

So, using static variables in a test is generally discouraged as it will defeat the whole purpose of one-instance-per-test to have a clean slate for each test.