How to use describeTo method of org.hamcrest.CustomMatcher class

@Mock creates a mock. @InjectMocks creates an instance of the class and injects the mocks that are created with the @Mock (or @Spy) annotations into this instance.

Note you must use @RunWith(MockitoJUnitRunner.class) or Mockito.initMocks(this) to initialize these mocks and inject them (JUnit 4).

With JUnit 5, you must use @ExtendWith(MockitoExtension.class).

@RunWith(MockitoJUnitRunner.class) // JUnit 4
// @ExtendWith(MockitoExtension.class) for JUnit 5
public class SomeManagerTest {

    @InjectMocks
    private SomeManager someManager;

    @Mock
    private SomeDependency someDependency; // this will be injected into someManager
 
     // tests...

}

No, there is no way to get EclEmma to notice the expected clause. They acknowledge this fact here.

Why are JUnit4 test cases with expected exceptions shown as not covered?

JUnit4 test cases with expected exceptions are shown as not covered even though they were executed. The reason for this is that underlying JaCoCo code coverage library only considers code as executed when certain probes are executed. For successful test cases marked with @Test{expected=...} this is not the case.

Personally, I wouldn't worry too much about it. Coverage of test cases is the least interesting thing EclEmma can tell you; I always completely ignore those metrics and focus on the coverage of my production code.

The @BeforeClass and @AfterClass annotated methods will be run exactly once during your test run - at the very beginning and end of the test as a whole, before anything else is run. In fact, they're run before the test class is even constructed, which is why they must be declared static.

The @Before and @After methods will be run before and after every test case, so will probably be run multiple times during a test run.

So let's assume you had three tests in your class, the order of method calls would be:

setUpBeforeClass()

  (Test class first instance constructed and the following methods called on it)
    setUp()
    test1()
    tearDown()

  (Test class second instance constructed and the following methods called on it)
    setUp()
    test2()
    tearDown()

  (Test class third instance constructed and the following methods called on it)
    setUp()
    test3()
    tearDown()

tearDownAfterClass()

You have to provide a delta to the assertion for Floats:

Assert.assertEquals(expected, actual, delta)

While delta is the maximum difference (delta) between expected and actual for which both numbers are still considered equal.

Assert.assertEquals(0.0012f, 0.0014f, 0.0002); // true
Assert.assertEquals(0.0012f, 0.0014f, 0.0001); //false

Using the Maven Surefire plugin and JUnit 5 together requires some tweaking ...

From the docs:

The JUnit team has developed a very basic provider for Maven Surefire that lets you run JUnit 4 and JUnit Jupiter tests via mvn test. The pom.xml file in the junit5-maven-consumer project demonstrates how to use it and can serve as a starting point.

Due to a memory leak in Surefire 2.20, the junit-platform-surefire-provider currently only works with Surefire 2.19.1.

...
<build>
    <plugins>
        ...
        <plugin>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.19</version>
            <dependencies>
                <dependency>
                    <groupId>org.junit.platform</groupId>
                    <artifactId>junit-platform-surefire-provider</artifactId>
                    <version>1.0.0</version>
                </dependency>
            </dependencies>
        </plugin>
    </plugins>
</build>
...

I'd suggest you use the newer assertThat() style asserts, which can easily describe all kinds of negations and automatically build a description of what you expected and what you got if the assertion fails:

assertThat(objectUnderTest, is(not(someOtherObject)));
assertThat(objectUnderTest, not(someOtherObject));
assertThat(objectUnderTest, not(equalTo(someOtherObject)));

All three options are equivalent, choose the one you find most readable.

To use the simple names of the methods (and allow this tense syntax to work), you need these imports:

import static org.junit.Assert.*;
import static org.hamcrest.CoreMatchers.*;

IMHO, yes they are still relevant.

With EJB3, you can test you EJB either like regular POJO, or as managed bean using an embedded EJB container.

Same for JPA, you can either embed a JPA implementation for your test and use an in-memory database, or you can mock the data layer completely.

For my last EJB project I had written a bit of glue code to test the EJB because embedded EJB container were not mature enough, but now I would go for an embedded EJB container + JUnit.

A few resources

• Blog post: How to unit test EJB 3 in 0.8 seconds
• SO question: Good unit testing resource for EJB

But there are many others easily findable

The reason is the autoboxing of Java. You use the method:

public static void assertSame(Object expected, Object actual)

It only works with Objects. When you pass ints to this method, Java automatically calls

Integer.valueOf( int i )

with these values. So the cast to int has no effect.

For values less than 128 Java has a cache, so assertSame() compares the Integer object with itself. For values greater than 127 Java creates new instances, so assertSame() compares an Integer object with another. Because they are not the same instance, the assertSame() method returns false.

You should use the method:

public static void assertEquals(Object expected, Object actual)

instead. This method uses the equals() method from Object.

OK, this is a bad thing to be doing. Don't mock a list; instead, mock the individual objects inside the list. See Mockito: mocking an arraylist that will be looped in a for loop for how to do this.

Also, why are you using PowerMock? You don't seem to be doing anything that requires PowerMock.

But the real cause of your problem is that you are using when on two different objects, before you complete the stubbing. When you call when, and provide the method call that you are trying to stub, then the very next thing you do in either Mockito OR PowerMock is to specify what happens when that method is called - that is, to do the thenReturn part. Each call to when must be followed by one and only one call to thenReturn, before you do any more calls to when. You made two calls to when without calling thenReturn - that's your error.