How to use ErrorCollector class of org.junit.rules package

The 'Should' convention is aligned with the behaviour driven development style of testing.

I personally really prefer to write tests in this style, as it encourages you to write tests that read as specifications, and are more aligned with the behaviour of the class or system that you are testing.

Where possible, I sometimes go one step further and give the test class even more context using it's name:

class ANewlyCreatedAccount {
  shouldHaveAZeroBalance() {}
  shouldCalculateItsOwnInterest() {}
}

By naming your classes and thinking about them in this specification style, this can give you a lot of guidance on which tests to write, and in which order you should write the tests and make them green.

Yes, 'should' vs 'test' is just a prefix and it's important to be consistent, but this question is also about the style and mindset of how you test your code and choose which tests to write. BDD has a ton of value, so I suggest reading further and give this a try.

You need to configure correctly your IDE.

Requirements

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-engine</artifactId>
    <version>5.4.0</version>
</dependency>

Do not use JUnit 5 that offers your IDE. If you add it as library, you will get:

No tests found for with test runner 'JUnit 5' 
==================== and this exception ===================
TestEngine with ID 'junit-vintage' failed to discover tests
java.lang.SecurityException: class "org.junit.jupiter.api.TestMethodOrder"'s signer information does not match signer information of other classes in the same package

So just include mentioned dependency only and your code will work as you expect:

import org.junit.jupiter.api.MethodOrderer;
import org.junit.jupiter.api.Order;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestMethodOrder;

@TestMethodOrder(MethodOrderer.OrderAnnotation.class)
public class FooServiceIT {

    @Test
    @Order(1)
    public void testUploadSuccess() {
        System.out.println("1");
    }

    @Test
    @Order(2)
    public void testDownloadSuccess() {
        System.out.println("2");
    }

    @Test
    @Order(3)
    public void testDeleteSuccess() {
        System.out.println("3");
    }
}

JUnit result:

1
2
3

You have defined a TransactionManager in your spring config but you are trying to execute a hibernate query in a method that is not transactional. Try adding @Transactional to your method or class.

If you have somewhat of a legacy Java application, and you're not allowed to change the visibility of your methods, the best way to test private methods is to use reflection.

Internally we're using helpers to get/set private and private static variables as well as invoke private and private static methods. The following patterns will let you do pretty much anything related to the private methods and fields. Of course, you can't change private static final variables through reflection.

Method method = TargetClass.getDeclaredMethod(methodName, argClasses);
method.setAccessible(true);
return method.invoke(targetObject, argObjects);

And for fields:

Field field = TargetClass.getDeclaredField(fieldName);
field.setAccessible(true);
field.set(object, value);

Notes:

1. TargetClass.getDeclaredMethod(methodName, argClasses) lets you look into private methods. The same thing applies for getDeclaredField.
2. The setAccessible(true) is required to play around with privates.

PowerMock is another mock framework that extends EasyMock and Mockito. With PowerMock you can easily remove unwanted behavior from a class, for example a static initializer. In your example you simply add the following annotations to your JUnit test case:

@RunWith(PowerMockRunner.class)
@SuppressStaticInitializationFor("some.package.ClassWithStaticInit")

PowerMock does not use a Java agent and therefore does not require modification of the JVM startup parameters. You simple add the jar file and the above annotations.

From the Spring Docs:

Prior to Spring 3.1, only path-based resource locations were supported. As of Spring 3.1, context loaders may choose to support either path-based or class-based resources. As of Spring 4.0.4, context loaders may choose to support path-based and class-based resources simultaneously.

However, with spring-test there is a small caveat. It uses the SmartContextLoader which is based on AbstractDelegatingSmartContextLoader and unfortunately it is not so smart ;)

@Override
public void processContextConfiguration(
        final ContextConfigurationAttributes configAttributes) {

    Assert.notNull(configAttributes, "configAttributes must not be null");
    Assert.isTrue(!(configAttributes.hasLocations() && configAttributes.hasClasses()), String.format(
        "Cannot process locations AND classes for context "
                + "configuration %s; configure one or the other, but not both.", configAttributes));

As shown in the code, locations and classes can not both be set.

So, how to fix this? Well, one solution is to add an extra config class such as the following:

@Configuration
@ImportResource("classpath:META-INF/dataContext.xml")
class TestConfig {

}

And, in your test code use the following:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = {Configuration.class, TestConfig.class})
@ActiveProfiles("test")
public class CityDaoImplTest { ... }

Technically, this is rewriting the configuration but you do not have to alter your existing config, just add a new @Configuration class (and that class can even be in the same file as your test case).

add ConstructorProperties:

• Create a lombok.config file in an appropriate location with the line: lombok.anyConstructor.addConstructorProperties = true
• Add lombok @Value annotation to your class to make it immutable

Then serialization and deserialization by Jackson works as expected.

This method:

• meets the criteria
• has less boilerplace than the previous top answer
• works on v1.16.20 (January 9th, 2018) and later

Edit: 2020-08-16

• Note: Using @Builder with @Value causes this solution to fail. (Thanks to comment from @guilherme-blanco below.) However, if you also add e.g. @AllArgsConstructor it does still work as expected.

Edit: 2021-08-19

• Note: When you add or change a lombok.config file the change is not picked up unless you do a rebuild (clean then build). I have been caught out by this a few times.
• @Jacksonized annotation solution is another method to achieve the desired outcome for the specific classes annotated. However, I personally prefer not to need to remember to annotate every class used for deserialization. Using lombok.config removes this overhead.

Take a look into JavaDocs of deprecated classes:

* @deprecated as of 1.4 in favor of
 * {@link org.springframework.boot.test.context.SpringBootTest} with
 * {@code webEnvironment=RANDOM_PORT} or {@code webEnvironment=DEFINED_PORT}.
 */
...
@Deprecated
public @interface WebIntegrationTest {

* @deprecated as of 1.4 in favor of {@link SpringBootTest} or direct use of
* {@link SpringBootContextLoader}.
*/
...
@Deprecated
public @interface SpringApplicationConfiguration {

Is there also a replacement for TestRestTemplate()?

Yes, here it is:

 * @deprecated as of 1.4 in favor of
 * {@link org.springframework.boot.test.web.client.TestRestTemplate}
 */
@Deprecated
public class TestRestTemplate extends RestTemplate {

You can use @TestPropertySource to override values in application.properties. From its javadoc:

test property sources can be used to selectively override properties defined in system and application property sources

For example:

@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = ExampleApplication.class)
@TestPropertySource(locations="classpath:test.properties")
public class ExampleApplicationTests {

}