刚接触单元测试遇到时间依赖的问题太正常了，我之前踩过不少坑，给你分享两个实用的方案——一个是用PowerMockito快速解决静态时间类的Mock，另一个是更优雅的解耦方式，以后维护起来更省心。

方案一：用PowerMockito Mock静态时间类（快速解决） #

如果你的工具类直接用了Calendar.getInstance()或者System.currentTimeMillis()这种静态方法，PowerMockito确实能帮你搞定。步骤很清晰：

1. 给测试类加必要注解
   因为要Mock静态方法，PowerMockito需要提前准备目标类，所以测试类上要加这两个注解：

   @RunWith(PowerMockRunner.class)
   @PrepareForTest(YourToolClass.class) // 这里填你要测试的工具类的全类名
   public class YourToolClassTest {
       // 测试方法写在这里
   }
   

2. Mock静态方法，返回固定时间
   比如你的工具类用Calendar.getInstance()获取当前时间，那我们可以创建一个固定时间的Calendar实例，让静态方法返回它：

   @Test
   public void testTimeDependentMethod() {
       // 1. 创建一个固定时间的Calendar（注意：Calendar的月份是从0开始的！January对应0）
       Calendar fixedCalendar = Calendar.getInstance();
       fixedCalendar.set(2024, Calendar.JANUARY, 1, 12, 0, 0); // 固定到2024年1月1日中午12点
   
       // 2. Mock Calendar的静态getInstance方法
       PowerMockito.mockStatic(Calendar.class);
       PowerMockito.when(Calendar.getInstance()).thenReturn(fixedCalendar);
   
       // 3. 调用工具类的方法
       YourToolClass tool = new YourToolClass();
       YourResult result = tool.yourTimeDependentMethod();
   
       // 4. 断言结果是否符合预期
       assertEquals(expectedResult, result);
   }
   

   如果你的方法用的是System.currentTimeMillis()，Mock方式类似：

   @Test
   public void testWithSystemTime() {
       long fixedTimestamp = 1704067200000L; // 对应2024-01-01 12:00:00的时间戳
       PowerMockito.mockStatic(System.class);
       PowerMockito.when(System.currentTimeMillis()).thenReturn(fixedTimestamp);
   
       // 后续调用方法、断言逻辑同上
   }
   

3. 清理静态Mock（可选但推荐）
   静态Mock可能会影响其他测试方法，建议在@After方法里重置：

   @After
   public void tearDown() {
       PowerMockito.reset(Calendar.class); // 或者System.class，根据你Mock的类来
   }
   

方案二：解耦时间依赖（更优雅，长期推荐） #

虽然PowerMockito能解决问题，但静态Mock会让测试和代码实现耦合，而且有时候会有奇怪的副作用。更好的方式是把时间获取的逻辑抽成独立组件，彻底解耦：

1. 定义时间提供者接口
   把获取时间的行为抽象成接口，这样我们可以在测试时替换实现：

   public interface TimeProvider {
       Calendar getCurrentCalendar();
       long getCurrentTimeMillis();
   }
   

2. 实现默认的时间提供者
   用系统时间实现这个接口，不影响原有代码的正常使用：

   public class DefaultTimeProvider implements TimeProvider {
       @Override
       public Calendar getCurrentCalendar() {
           return Calendar.getInstance();
       }
   
       @Override
       public long getCurrentTimeMillis() {
           return System.currentTimeMillis();
       }
   }
   

3. 改造工具类，注入TimeProvider
   给工具类加一个带参数的构造方法，用于测试时传入Mock的TimeProvider；同时保留无参构造，用默认实现，不影响原有业务代码：

   public class YourToolClass {
       private final TimeProvider timeProvider;
   
       // 测试用的构造方法，注入自定义TimeProvider
       public YourToolClass(TimeProvider timeProvider) {
           this.timeProvider = timeProvider;
       }
   
       // 业务代码用的无参构造，默认用系统时间
       public YourToolClass() {
           this(new DefaultTimeProvider());
       }
   
       // 你的时间依赖方法，现在通过timeProvider获取时间
       public YourResult yourTimeDependentMethod() {
           Calendar now = timeProvider.getCurrentCalendar();
           // 原来的业务逻辑不变，只是获取时间的地方换成timeProvider
           ...
       }
   }
   

4. 测试时Mock TimeProvider
   现在不需要PowerMockito了，用普通的Mockito就能搞定，测试更干净：

   @Test
   public void testTimeDependentMethodWithMockProvider() {
       // 1. 创建固定时间的Calendar
       Calendar fixedCalendar = Calendar.getInstance();
       fixedCalendar.set(2024, Calendar.JANUARY, 1, 12, 0, 0);
   
       // 2. Mock TimeProvider接口
       TimeProvider mockTimeProvider = Mockito.mock(TimeProvider.class);
       Mockito.when(mockTimeProvider.getCurrentCalendar()).thenReturn(fixedCalendar);
   
       // 3. 初始化工具类，传入Mock的TimeProvider
       YourToolClass tool = new YourToolClass(mockTimeProvider);
       YourResult result = tool.yourTimeDependentMethod();
   
       // 4. 断言结果
       assertEquals(expectedResult, result);
   }
   

额外小提示 #

• 如果你的项目用Java 8+，强烈推荐用LocalDateTime、Instant这些新的日期时间API，它们是不可变类，测试起来更安全。Mock方式类似，比如可以MockClock类，或者同样用时间提供者的方式注入Clock。
• 记住Calendar的月份是0-based的！January对应0，February对应1，这个坑很多人都踩过，别大意。

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