Spring Framework Testing Concepts
External
Internal
Overview
Proper deployment of dependency injection makes both unit and integration testing easier, in that the presence of setter methods and appropriate constructors on classes makes them easier to wire together in a test without having to set up service locator registries or similar structures.
Unit Tests
According to Spring reference documentation, a Spring unit test is a test that does not use a real application context. The unit test should work without such a real application context, and use objects created with the new operator and injected with a direct invocation of the constructor or setter methods. Spring provides MockEnvironment and MockPropertySource that are useful for developing out-of-container tests. Understand this.
Integration Tests
According to Spring reference documentation, a Spring integration test is a test where dependencies are injected with the help of a real application context, albeit a special, test-oriented implementation of it. Yet, these tests do not rely on the presence of an application server, a Spring Boot instance or a deployment environment. These tests are slower to run than unit tests, but much faster than the equivalent Selenium or remote tests, that rely on deployment in an actual deployment environment.
Spring provides an integration testing framework, named Spring TestContext Framework. The framework is annotation-driven, and aims to provide the following:
- Context management and caching between tests. This generally speeds up successive tests.Clarify if this refers to test functions (@Test) within the same test class, or refers to test functions belonging to different test classes.
- Dependency injection of test fixture instances.
- Transaction management. The tests can be coded assuming existence of a transaction.
- Spring-specific base classes.
Spring TestContext Framework Dependency
dependencies {
testImplementation('org.springframework:spring-test')
}
This dependency declaration assumes that we are using Gradle Spring dependency-management Plugin and a Maven BOM.
Integration Test Programming Model
Spring TestContext Framework requires a specialized test runner, implemented by the SpringRunner class, which is configured with the @RunWith annotation. The SpringRunner class is an extension of JUnit's BlockJUnit4ClassRunner, which provides functionality of the Spring TestContext Framework to standard JUnit tests. The essential piece of the SpringRunner is a TestContextManager instance, which manages a single TestContext and sends signaling events to all registered TestExecutionListeners.
The test application context is loaded and configured based on the configuration specified with @ContextConfiguration. For configuration details, see:
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringRunner;
@RunWith(SpringRunner.class)
@ContextConfiguration(classes = {
AComponent.class,
BComponent.class})
public class AComponentIntegrationTests {
@Autowired
private AComponent aComponent;
@Test
public void realContextInjectsComponent() {
assertNotNull(aComponent);
}
}
Activating Profiles for Integration Tests
Tests are allowed to use a special annotation to declare what profile or profiles are active when the test is executed. That annotation is @ActiveProfiles.
@RunWith(SpringRunner.class)
@ContextConfiguration(classes = {...})
@ActiveProfiles("heavy")
public class HeavyIntegrationTest {
...
}
The above declaration says that the "heavy" profile will be active while HeavyIntegrationTest is executed.
Playground Example
Annotations
Test Logging
When building with Gradle, stdout and stderr of the tests being executed will be shown at the console if the following are configured:
- Set testLogging.showStandardStreams of the Java plugin Test task, as shown here: Show stdout and stderr of the Test JVM on the Console.
- Make sure that a slf4j binding is in the test classpath. Spring uses Logback by default, so the following will work: Place Logback Binding on test classpath.
- Place a logback.xml configuration in src/test/resources. At the time of the writing, I was not able to figure out why logging configuration from src/test/resources/application.yml did not work.
Using Property Configuration Holders with Plain Spring TestContext Framework
Property configuration holders are a Spring Boot pattern. They require Spring Boot dependencies and runtime to function. However, they're useful, so this is a method to get them to work with plain TestContext Framework tests:
Concurrent Test Execution
Concurrent test execution is supported by Spring Test Context Framework that comes with Spring 5. JUnit 4 or newer is needed.
When Gradle is used to run the build, the tests are executed by default in a separate (forked) JVM. More than one JVMs dedicated to testing can be configured with maxParallelForks.
Within the context of the same test class, all test methods are by default executed serially, by the same thread. However, the order in which the methods are executed does not coincide with the order in which the methods are declared in class.
Integration tests, whether executed concurrently or not, share the same context and the context's singletons. Even if the tests are executed serially, a context singleton's state changes introduced by the execution of one of the tests are visible to the subsequent tests, from different classes.