How to use assertNull method of junit.framework.TestCase class

For @Async semantics to be adhered, some active @Configuration class will have the @EnableAsync annotation, e.g.

@Configuration
@EnableAsync
@EnableScheduling
public class AsyncConfiguration implements AsyncConfigurer {

  //

}

To resolve my issue, I introduced a new Spring profile non-async.

If the non-async profile is not active, the AsyncConfiguration is used:

@Configuration
@EnableAsync
@EnableScheduling
@Profile("!non-async")
public class AsyncConfiguration implements AsyncConfigurer {

  // this configuration will be active as long as profile "non-async" is not (!) active

}

If the non-async profile is active, the NonAsyncConfiguration is used:

@Configuration
// notice the missing @EnableAsync annotation
@EnableScheduling
@Profile("non-async")
public class NonAsyncConfiguration {

  // this configuration will be active as long as profile "non-async" is active

}

Now in the problematic JUnit test class, I explicitly activate the "non-async" profile in order to mutually exclude the async behavior:

@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = Application.class)
@WebAppConfiguration
@IntegrationTest
@Transactional
@ActiveProfiles(profiles = "non-async")
public class SomeServiceIntTest {

    @Inject
    private SomeService someService;

        @Test
        public void testAsyncMethod() {

            Foo testData = prepareTestData();

            someService.asyncMethod(testData);

            verifyResults();
        }

        // verifyResult() with assertions, etc.
}

As has been said in other responses, the order in which JUnit finds methods is not guaranteed, so the execution order of @Before methods can't be guaranteed. The same is true of @Rule, it suffers from the same lack of guarantee. If this will always be the same code, then there isn't any point in splitting into two methods.

If you do have two methods, and more importantly, if you wish to use them from multiple places, then you can combine rules using a RuleChain, which was introduced in 4.10. This allows the specific ordering of rules, such as:

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);
  }
}

This produces:

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

So you can either upgrade to 4.10 or just steal the class.

In your case, you could define two rules, one for client setup and one for object, and combine them in a RuleChain. Using ExternalResource.

public static class UsesExternalResource {
  private TestRule clientRule = new ExternalResource() {
      @Override
      protected void before() throws Throwable {
        setupClientCode();
      };

      @Override
      protected void after() {
        tearDownClientCode()
    };
  };

  @Rule public TestRule chain = RuleChain
                   .outerRule(clientRule)
                   .around(objectRule);
}

So you'll have the following execution order:

clientRule.before()
objectRule.before()
the test
objectRule.after()
clientRule.after()

your inner configuration class will not work unless you add a static keyword before its definition. However you should know that for the @Sql annotation

Path Resource Semantics

Each path will be interpreted as a Spring Resource. A plain path — for example, "schema.sql" — will be treated as a classpath resource that is relative to the package in which the test class is defined. A path starting with a slash will be treated as an absolute classpath resource, for example: "/org/example/schema.sql". A path which references a URL (e.g., a path prefixed with classpath:, file:, http:, etc.) will be loaded using the specified resource protocol.

So try to prefix the value inside @Sql with classpath: like this :

@Sql(scripts={"classpath:data.sql"})

Good luck!

Although I agree with @assylias that using @BeforeClass is a classic solution it is not always convenient. The method annotated with @BeforeClass must be static. It is very inconvenient for some tests that need instance of test case. For example Spring based tests that use @Autowired to work with services defined in spring context.

In this case I personally use regular setUp() method annotated with @Before annotation and manage my custom static(!) boolean flag:

private static boolean setUpIsDone = false;
.....
@Before
public void setUp() {
    if (setUpIsDone) {
        return;
    }
    // do the setup
    setUpIsDone = true;
}

This works for me:

• mvn clean install works (with junit tests)
• IDEA recognizes module language level correctly as 12 (Preview) - Switch expressions
• junit tests in IDEA work

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
        <configuration>
            <release>12</release>
            <compilerArgs>
                <arg>--enable-preview</arg>
            </compilerArgs>
        </configuration>
    </plugin>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>2.22.2</version>
        <configuration>
            <argLine>--enable-preview</argLine>
        </configuration>
    </plugin>

Environment:

• Ubuntu 18.04.3 x64

• IDEA 2019.2.1

• Maven 3.6.0

• jdk:

   IMPLEMENTOR="Oracle Corporation"
   JAVA_VERSION="12"
   JAVA_VERSION_DATE="2019-03-19"
  

ADDITION: Similarly this approach works for java 13.

ADDITION: Similarly this approach works for java 17.

Validate.isTrue and 'assert' serve completely different purposes.

assert
Java's assert statements are typically used for documenting (by means of assertions) under what circumstances methods can be invoked, and what their callers can expect to be true afterward. The assertions can optionally be checked at run time, resulting in an AssertionError exception if they don't hold.

In terms of design-by-contract, assertions can be used to define pre- and postconditions as well as class invariants. If at run time these are detected not to hold, this points to a design or implementation problem in the system.

Validate.isTrue
org.apache.commons.lang.Validate is different. It offers a simple set of JUnit-like methods which check a condition, and throw an "IllegalArgumentException" if the condition does not hold.

It is typically used when a public API should be tolerant against bad input. In that case, its contract can promise to throw an IllegalArgumentException upon erroneous input. Apache Validate offers a convenient shorthand for implementing this.

Since an IllegalArgumentException is thrown, it does not make sense to use Apache's Validate to check postconditions or invariants. Likewise, it is incorrect to use 'assert' for user input validation, since assertion checking can be disabled at run time.

Using both
It is possible, though, to use both at the same time, albeit for different purposes. In this case, the contract should explicitly require IllegalArgumentException to be raised upon certain types of input. This is then implemented via Apache Validate. Invariants and postconditions are then simply asserted, as well as possible additional preconditions (for example affecting the state of the object). For example:

public int m(int n) {
  // the class invariant should hold upon entry;
  assert this.invariant() : "The invariant should hold.";

  // a precondition in terms of design-by-contract
  assert this.isInitialized() : "m can only be invoked after initialization.";

  // Implement a tolerant contract ensuring reasonable response upon n <= 0:
  // simply raise an illegal argument exception.
  Validate.isTrue(n > 0, "n should be positive");

  // the actual computation.
  int result = complexMathUnderTrickyCircumstances(n);

  // the postcondition.
  assert result > 0 : "m's result is always greater than 0.";
  assert this.processingDone() : "processingDone state entered after m.";
  assert this.invariant() : "Luckily the invariant still holds as well.";

  return result;
}

More information:

• Bertrand Meyer, "Applying Design by Contract", IEEE Computer, 1992 (pdf)
• Johsua Bloch. Effective Java, 2nd ed., Item 38. Check parameters for validity. (google books)

A note for people using Junit5, we need to include the below to enable it - that is, running junit5 tests is not enabled by default.

test {
  useJUnitPlatform()
}

Call the void method of the mock. Afterwards use EasyMock.expectLastCall().anyTimes()

The following config works for me.

File: build.gradle

testCompile("junit:junit:4.12")
testCompile("org.springframework.boot:spring-boot-starter-test")

File: MYServiceTest.java

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.ActiveProfiles;
import org.springframework.test.context.junit4.SpringRunner;

@SpringBootTest(classes = Application.class,
    webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@ActiveProfiles("test")
@RunWith(SpringRunner.class)
public class MYServiceTest {

    @Autowired
    private MYService myService;

    @Test
    public void test_method() {
        myService.run();
    }
}