Introduce NoOpTaskScheduler for disabling @Scheduled tasks in test setups

[membersound]

If an application defines a @Scheduled(fixedRateString = "PT6H") tasks, then this task will be running on any @SpringBootTest junit test that does not explicit mock the bean containing the scheduled task.

@Service
public class SchedulerService {
    @Scheduled(fixedRateString = "PT6H")
    public void runOnStartup() {

   }
}

This gets tedious if there are many more @Scheduled tasks in the application that launch on startup by usage of fixedRate or fixedRateString.

It would be great if there could be a possibility to completely deactivate the execution of @Scheduled tasks in junit.

Just like it is possible to deactivate any @Cacheable annotation by simply setting spring.cache.type=none dring junit tests.

Something like: spring.enable.scheduling=false (default: true)

[wilkinsona]

Boot has no control over whether or not scheduling is enabled as it's done in your code via @EnableScheduling. If you'd like a global property that can override @EnableScheduling (similar to Spring Framework's spring.jndi.ignore) this would have to be a Framework change. We've transferred your issue for the Framework team's consideration.

In the meantime, you could structure your code so that your @EnableScheduling-annotated class can be excluded when running your tests. One way to achieve that would be to use something like@Profile("!test") on the class that enables scheduling and then activate the test profile in your tests where you do not want scheduling to be enabled.

[Drezir]

I have tried to create this, please look at the patch I am sending. Thank you
Option_to_disable_scheduling.patch.zip
.

[snicoll]

Spring Framework has support for a no-op cache so I wonder if offering a no-op TaskScheduler would be a way to provide a consistent support here.

@wilkinsona if we did that, would you be ok to introduce a similar support in Spring Boot? I am asking as the example of caching is similar and yet Spring Boot is able to provide such a feature. The only difference is the lack of a no-op implementation.

[wilkinsona]

That sounds fine, I think. I guess we'd do it through a new spring.task.scheduling.* property that auto-configures a no-op TaskScheduler instead of the existing one.

[snicoll]

paging @jhoeller to see what he thinks of that idea.