你遇到的这个问题其实是Spring Scheduler的底层机制导致的——它默认依赖系统时钟的渐进式推进，手动跳变系统日期/时间会打乱它的任务触发计算逻辑，所以直接改系统时间测试跨天调度会踩坑。下面给你几个靠谱的高效测试方法，不用等一整天：

方法一：抽离业务逻辑，单独测试 #

先把调度任务里的核心业务逻辑抽成独立的Service组件，这样你可以直接在单元测试中调用这个Service的方法，验证业务逻辑的正确性，完全不用依赖调度器的触发逻辑。

比如重构你的代码：

// 新的业务Service
@Service
public class TransactionStatusService {
    private static final Logger log = LoggerFactory.getLogger(TransactionStatusService.class);

    public void checkTransactionStatus() {
        // 原来的核心业务逻辑
        log.info("TEST 1");
    }
}

// 调度类只负责触发调用
@Component
@Slf4j
public class JobScheduler {
    private final TransactionStatusService statusService;

    // 构造注入
    public JobScheduler(TransactionStatusService statusService) {
        this.statusService = statusService;
    }

    @Scheduled(cron = "0 1 1 ? * *")
    public void checkTransactionStatusInBank() {
        statusService.checkTransactionStatus();
    }
}

这样单元测试只需要专注测试TransactionStatusService的功能，而调度触发的逻辑可以用下面的方法单独验证。

方法二：用自定义可控制的时钟替换系统时钟 #

Spring 5.3+开始支持给ThreadPoolTaskScheduler设置自定义Clock，我们可以利用这个特性，创建一个可手动调整的时钟Bean，让调度器使用这个时钟来计算任务触发时间，完全不受系统时间的影响。

1. 先定义一个可配置的时钟配置类：

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import java.time.Clock;
import java.time.Instant;
import java.time.ZoneId;

@Configuration
public class TestSchedulerConfig {
    private Clock customClock = Clock.systemDefaultZone();

    @Bean
    public Clock clock() {
        return customClock;
    }

    // 提供外部修改时钟时间的方法
    public void setClockTime(Instant newInstant) {
        this.customClock = Clock.fixed(newInstant, ZoneId.systemDefault());
    }
}

2. 自定义TaskScheduler，绑定这个时钟：

@Bean
public TaskScheduler taskScheduler(Clock clock) {
    ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler();
    scheduler.setClock(clock); // 让调度器使用我们自定义的时钟
    scheduler.setPoolSize(5);
    scheduler.setThreadNamePrefix("scheduled-task-");
    return scheduler;
}

3. 在Spring Boot测试类中，手动调整时钟到目标时间，验证任务是否触发：

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.mock.mockito.MockBean;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.times;
import java.time.Instant;
import java.time.LocalDateTime;
import java.time.ZoneId;

@SpringBootTest
class SchedulerTriggerTest {
    @Autowired
    private TestSchedulerConfig schedulerConfig;
    @Autowired
    private TransactionStatusService statusService;

    @Test
    void testDailyTaskTrigger() throws InterruptedException {
        // 设置时钟到次日凌晨1:00，再过1分钟就到触发时间
        Instant testTime = LocalDateTime.of(2024, 5, 20, 1, 0)
                .atZone(ZoneId.systemDefault())
                .toInstant();
        schedulerConfig.setClockTime(testTime);

        // 等待1分10秒，确保调度器有足够时间计算并触发任务
        Thread.sleep(61000);

        // 验证业务方法被调用了一次
        verify(statusService, times(1)).checkTransactionStatus();
    }
}

方法三：临时修改Cron表达式快速验证基础功能 #

如果你只是想快速确认调度器本身能正常触发任务，可以临时把cron表达式改成每分钟执行一次：

@Scheduled(cron = "0 */1 * ? * *")

启动应用后，每分钟都会触发任务，能快速验证调度是否正常工作。测试完成后再改回原来的0 1 1 ? * *即可。这种方法适合快速验证调度器的基本可用性，但没法精准测试跨天的触发场景，结合方法二使用效果更好。

为什么手动改系统时间会失效？ #

Spring默认的ThreadPoolTaskScheduler是基于系统时钟的绝对时间来计算下一次触发时间的。当你第一次把系统时间设为1:00启动应用，调度器会计算出下一次触发时间是当天1:01；但当你手动把时间跳到次日1:00，调度器会认为当前时间还没到它之前计算的“下一次触发时间”（因为它不知道你跳了天），所以不会触发任务。而自定义时钟的方式可以让调度器完全使用我们可控的时间，避免这个问题。

内容的提问来源于stack exchange，提问作者Sanish Maharjan