Expand Authors Top

If you have a few years of experience in the Java ecosystem and you’d like to share that with the community, have a look at our Contribution Guidelines.

Expanded Audience – Frontegg – Security (partner)
announcement - icon User management is very complex, when implemented properly. No surprise here.

Not having to roll all of that out manually, but instead integrating a mature, fully-fledged solution - yeah, that makes a lot of sense.
That's basically what Frontegg is - User Management for your application. It's focused on making your app scalable, secure and enjoyable for your users.
From signup to authentication, it supports simple scenarios all the way to complex and custom application logic.

Have a look:

>> Elegant User Management, Tailor-made for B2B SaaS

NPI – Spring Top – Temp – Non-Geo (Lightrun)

Get started with Spring 5 and Spring Boot 2, through the reference Learn Spring course:

>> LEARN SPRING
NPI – Lightrun – Spring (partner)

We rely on other people’s code in our own work. Every day. It might be the language you’re writing in, the framework you’re building on, or some esoteric piece of software that does one thing so well you never found the need to implement it yourself.

The problem is, of course, when things fall apart in production - debugging the implementation of a 3rd party library you have no intimate knowledge of is, to say the least, tricky. It’s difficult to understand what talks to what and, specifically, which part of the underlying library is at fault.

Lightrun is a new kind of debugger.

It's one geared specifically towards real-life production environments. Using Lightrun, you can drill down into running applications, including 3rd party dependencies, with real-time logs, snapshots, and metrics. No hotfixes, redeployments, or restarts required.

Learn more in this quick, 5-minute Lightrun tutorial:

>> The Essential List of Spring Boot Annotations and Their Use Cases

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.

Spring bottom

Get started with Spring 5 and Spring Boot 2, through the Learn Spring course:

>> THE COURSE
Junit footer banner
Comments are closed on this article!