1. Overview
In this tutorial, we’ll show how we can prevent beans of type of ApplicationRunner or CommandLineRunner from running during Spring Boot integration tests.
2. Example Application
Our example application consists of a command-line runner, an application runner, and a task service bean.
The command-line runner, calls the task service’s execute method, in order to perform a task on application startup:
@Component
public class CommandLineTaskExecutor implements CommandLineRunner {
private TaskService taskService;
public CommandLineTaskExecutor(TaskService taskService) {
this.taskService = taskService;
}
@Override
public void run(String... args) throws Exception {
taskService.execute("command line runner task");
}
}
In the same manner, the application runner interacts with the task service to perform another task:
@Component
public class ApplicationRunnerTaskExecutor implements ApplicationRunner {
private TaskService taskService;
public ApplicationRunnerTaskExecutor(TaskService taskService) {
this.taskService = taskService;
}
@Override
public void run(ApplicationArguments args) throws Exception {
taskService.execute("application runner task");
}
}
Finally, the task service is responsible for executing its client’s tasks:
@Service
public class TaskService {
private static Logger logger = LoggerFactory.getLogger(TaskService.class);
public void execute(String task) {
logger.info("do " + task);
}
}
And, we’ve also got a Spring Boot application class that makes it all work:
@SpringBootApplication
public class ApplicationCommandLineRunnerApp {
public static void main(String[] args) {
SpringApplication.run(ApplicationCommandLineRunnerApp.class, args);
}
}
3. Testing Expected Behavior
The ApplicationRunnerTaskExecutor and the CommandLineTaskExecutor run after Spring Boot loads the application context.
We can verify this with a simple test:
@SpringBootTest
class RunApplicationIntegrationTest {
@SpyBean
ApplicationRunnerTaskExecutor applicationRunnerTaskExecutor;
@SpyBean
CommandLineTaskExecutor commandLineTaskExecutor;
@Test
void whenContextLoads_thenRunnersRun() throws Exception {
verify(applicationRunnerTaskExecutor, times(1)).run(any());
verify(commandLineTaskExecutor, times(1)).run(any());
}
}
As we see, we’re using the SpyBean annotation for applying Mockito spies to the ApplicationRunnerTaskExecutor and CommandLineTaskExecutor beans. By doing so, we can verify that the run method of each of these beans was called one time.
In the next sections, we are going to see various ways and techniques for preventing this default behavior during our Spring Boot integration tests.
4. Prevention via Spring Profiles
One way that we can prevent these two from running is by annotating them with @Profile:
@Profile("!test")
@Component
public class CommandLineTaskExecutor implements CommandLineRunner {
// same as before
}
@Profile("!test")
@Component
public class ApplicationRunnerTaskExecutor implements ApplicationRunner {
// same as before
}
After the above changes, we proceed with our integration test:
@ActiveProfiles("test")
@SpringBootTest
class RunApplicationWithTestProfileIntegrationTest {
@Autowired
private ApplicationContext context;
@Test
void whenContextLoads_thenRunnersAreNotLoaded() {
assertNotNull(context.getBean(TaskService.class));
assertThrows(NoSuchBeanDefinitionException.class,
() -> context.getBean(CommandLineTaskExecutor.class),
"CommandLineRunner should not be loaded during this integration test");
assertThrows(NoSuchBeanDefinitionException.class,
() -> context.getBean(ApplicationRunnerTaskExecutor.class),
"ApplicationRunner should not be loaded during this integration test");
}
}
As we see, *we annotated the above test class with the @ActiveProfiles(“test”) annotation, which means it will not wire those annotated with @Profile(“!test”).* As a result, neither the CommandLineTaskExecutor bean nor the ApplicationRunnerTaskExecutor bean is loaded at all.
5. Prevention via the ConditionalOnProperty Annotation
Or, we can configure their wiring by property and then use the ConditionalOnProperty annotation:
@ConditionalOnProperty(
prefix = "application.runner",
value = "enabled",
havingValue = "true",
matchIfMissing = true)
@Component
public class ApplicationRunnerTaskExecutor implements ApplicationRunner {
// same as before
}
@ConditionalOnProperty(
prefix = "command.line.runner",
value = "enabled",
havingValue = "true",
matchIfMissing = true)
@Component
public class CommandLineTaskExecutor implements CommandLineRunner {
// same as before
}
As we see, the ApplicationRunnerTaskExecutor and the CommandLineTaskExecutor are enabled by default, and we can disable them if we set the following properties to false:
- command.line.runner.enabled
- application.runner.enabled
So, in our test, we set these properties to false and neither the ApplicationRunnerTaskExecutor nor the CommandLineTaskExecutor beans are loaded to the application context:
@SpringBootTest(properties = {
"command.line.runner.enabled=false",
"application.runner.enabled=false" })
class RunApplicationWithTestPropertiesIntegrationTest {
// same as before
}
Now, although the above techniques help us to achieve our goal, there are cases where we want to test that all the Spring beans are loaded and wired correctly.
For instance, we may want to test that the TaskService bean is injected correctly to the CommandLineTaskExecutor, but we still don’t want its run method to be executed during our test. So, let’s see the last section that explains how we can achieve that.
6. Prevention by Not Bootstrapping the Entire Container
Here, we’ll describe how we can prevent the CommandLineTaskExecutor and ApplicationRunnerTaskExecutor beans from execution by not bootstrapping the entire application container.
In the previous sections, we used the @SpringBootTest annotation and this resulted in the entire container to be bootstrapped during our integration tests. @SpringBootTest includes two meta-annotations that are relevant to this last solution:
@BootstrapWith(SpringBootTestContextBootstrapper.class)
@ExtendWith(SpringExtension.class)
Well, if there’s no need to bootstrap the entire container during our test, then don’t want to use @BootstrapWith.
Instead, we can replace it with @ContextConfiguration:
@ContextConfiguration(classes = {ApplicationCommandLineRunnerApp.class},
initializers = ConfigDataApplicationContextInitializer.class)
With @ContextConfiguration, we determine how to load and configure the application context for integration tests. By setting the ContextConfiguration classes property, we declare that Spring Boot should use the ApplicationCommandLineRunnerApp class to load the application context. By defining the initializer to be the ConfigDataApplicationContextInitializer, the application loads its properties.**
We still need @ExtendWith(SpringExtension.class) since that integrates the Spring TestContext Framework into JUnit 5’s Jupiter programming model.
As a result of the above, the Spring Boot application context loads the application’s components and properties without executing the CommandLineTaskExecutor or the ApplicationRunnerTaskExecutor beans:
@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = { ApplicationCommandLineRunnerApp.class },
initializers = ConfigDataApplicationContextInitializer.class)
public class LoadSpringContextIntegrationTest {
@SpyBean
TaskService taskService;
@SpyBean
CommandLineRunner commandLineRunner;
@SpyBean
ApplicationRunner applicationRunner;
@Test
void whenContextLoads_thenRunnersDoNotRun() throws Exception {
assertNotNull(taskService);
assertNotNull(commandLineRunner);
assertNotNull(applicationRunner);
verify(taskService, times(0)).execute(any());
verify(commandLineRunner, times(0)).run(any());
verify(applicationRunner, times(0)).run(any());
}
}
Also, we have to keep in mind that the ConfigDataApplicationContextInitializer, when it is used alone, does not provide support for @Value(“${…}”) injection. If we want to support it we have to configure a PropertySourcesPlaceholderConfigurer.
7. Conclusion
In this article, we showed various ways of preventing the execution of the ApplicationRunner and CommandLineRunner beans during Spring Boot integration tests.
As always, the code is available over on GitHub.