How to use Ordering class of org.junit.runner.manipulation package

With AssertJ, another option would be to use returns:

import static org.assertj.core.api.Assertions.from;

assertThat(product)
    .returns("Coat", from(Product::getName))
    .returns(true, from(Product::getAvailable))
     //
     // or without 'from()'
     //
    .returns(12, Product::getAmount)
    .returns(new BigDecimal("88.0"), Product::getPrice);

A bit more verbose but I find it easier to read compared to extracting/contains.

Note that from is just an optional syntax sugar to improve readability.

Since 3.22.0, doesNotReturn is also available. This can be useful for non-null fields where the expected value is not known in advance.

assertThat(product)
    .returns("Coat", from(Product::getName))
    .returns(true, from(Product::getAvailable))
    .doesNotReturn(42, from(Product::getAmount))
    .doesNotReturn(null, from(Product::getPrice));

Fix could be as simple as clicking run/skip all breakpoints. Worked for me.

In Maven compile and testCompile goals are different. And Maven even has parameters for testCompile: testTarget and testSource. So:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.0</version>
    <configuration>
        <source>1.7</source>
        <target>1.7</target>
        <testSource>1.8</testSource>
        <testTarget>1.8</testTarget>
    </configuration>
</plugin>

You need to make sure you have your repos set up, and you need to include the dependency for junit. This means that you need something that looks like this for your build.gradle

repositories {
    mavenCentral()
}

apply plugin: 'java'

dependencies {
    testCompile 'junit:junit:4.10'
}

Mockito 2 now supports final classes and methods!

But for now that's an "incubating" feature. It requires some steps to activate it which are described in What's New in Mockito 2:

Mocking of final classes and methods is an incubating, opt-in feature. It uses a combination of Java agent instrumentation and subclassing in order to enable mockability of these types. As this works differently to our current mechanism and this one has different limitations and as we want to gather experience and user feedback, this feature had to be explicitly activated to be available ; it can be done via the mockito extension mechanism by creating the file src/test/resources/mockito-extensions/org.mockito.plugins.MockMaker containing a single line:

mock-maker-inline

After you created this file, Mockito will automatically use this new engine and one can do :

 final class FinalClass {
   final String finalMethod() { return "something"; }
 }

 FinalClass concrete = new FinalClass(); 

 FinalClass mock = mock(FinalClass.class);
 given(mock.finalMethod()).willReturn("not anymore");

 assertThat(mock.finalMethod()).isNotEqualTo(concrete.finalMethod());

In subsequent milestones, the team will bring a programmatic way of using this feature. We will identify and provide support for all unmockable scenarios. Stay tuned and please let us know what you think of this feature!

EDIT: With the recently released Junit 4.10, you can use RuleChain to chain rules correctly (see at the end).

You could introduce another private field without the @Rule annotation, then you can reorder your code as you wish:

public class FolderRuleOrderingTest {

    private TemporaryFolder privateFolder = new TemporaryFolder();

    @Rule
    public MyNumberServer server = new MyNumberServer(privateFolder);

    @Rule
    public TemporaryFolder folder = privateFolder;

    @Test
    public void testMyNumberServer() throws IOException {
        server.storeNumber(10);
        assertEquals(10, server.getNumber());
    }
    ...
}

The cleanest solution is to have a compound rule, but the above should work.

EDIT: With the recently released Junit 4.10, you can use RuleChain to chain rules correctly:

public static class UseRuleChain {
   @Rule
   public TestRule chain = RuleChain
                          .outerRule(new LoggingRule("outer rule"))
                          .around(new LoggingRule("middle rule"))
                          .around(new LoggingRule("inner rule"));

   @Test
   public void example() {
           assertTrue(true);
   }
}

writes the log

starting outer rule
starting middle rule
starting inner rule
finished inner rule
finished middle rule
finished outer rule

Add hamcrest-all-X.X.jar to your classpath.

Latest version as of Feb 2015 is 1.3: http://code.google.com/p/hamcrest/downloads/detail?name=hamcrest-all-1.3.jar&can=2&q=

JUnit creates a new instance of test class each time it runs a new test method and runs @Before method each time it creates a new test class. You can easily test it:

@Before
public void setup() {
    System.out.println("setup");
    when(myMock.myMethod()).thenReturn("hello");
}

And MockitoJUnitRunner will create a new MyMock mock instance for every test method.

I've come across that situation several times and, after a lot of attempts, I found the solution.

Check your project build-path and enable specific output folders for each folder. Go one by one though each source-folder of your project and set the output folder that maven would use.

For example, your web project's src/main/java should have target/classes under the web project, test classes should have target/test-classes also under the web project and so.

Using this configuration will allow you to execute unit tests in eclipse.

Just one more advice, if your web project's tests require some configuration files that are under the resources, be sure to include that folder as a source folder and to make the proper build-path configuration.