使用 JUnit/Mockito 来确认 java.util.Timer.schedule()

Question

我在 JUnit/Mockito 中看到了很多关于基于时间的测试技术的帖子，但似乎有很多考虑因素，以至于我对我应该如何考虑自己的测试代码感到困惑 - 以及如何/究竟是什么我应该测试。我的测试代码如下：class ClassUnderTest {    Clock clock; // Thought this might be a useful DI, but not sure how...    String delayString;    Timer timer;    public ClassUnderTest(String delayString, Clock clock) {        this.clock = clock;        this.delayString = delayString;        init();    }    private void init() {        ChronoUnit unit = parseDelayStringToGetUnit(); // Implementation not shown here        Integer amountOfTime = parseDelayStringToGetAmount(); // Implementation not shown here        long delay = calculateDelay(unit, amountOfTime); // Implementation not show here        timer.schedule(new TimerTask() {            @Override            public void run() {                taskToRun();            }        }, delay);    }    private void taskToRun() {        // Does something after a delay        // Happy to amend signature to take params or return a value ...    }}诚然，它被削减了很多，但我想削减一些不重要的东西。它的基本功能是在实例化时调用 taskToRun() 但只有在解析另一个传递的字符串之后才能将其反序列化为 ChronoUnit 和相关数量。传入的延迟长度可能有限，但可能从 15 分钟到 8 小时不等。我已经读到我不需要测试计时器本身，但我仍然觉得我的测试方法应该确认 taskToRun() 确实最终运行，但不会在所需的延迟到期之前运行。我认为将 java.time.Clock 作为依赖项注入传递将有助于基于时间的测试，但目前我看不到（这里）如何并且显然它没有用于任何事情（还）。我要测试的内容原则上是否正确，如果是，我该如何去做？编辑：道歉。刚刚意识到 delayString 还包括“epochStart”，即延迟应该开始的瞬间。原始“延迟”的当前计算将改为计算：InstantWhenDelayExpires = epochStart +（ChronoUnit 的数量）然后计时器将使用 instantWhenDelayExpires 而不是延迟量进行调度。我不认为这让我的问题特别复杂？

Answer 1

但我仍然觉得我的测试方法应该确认 taskToRun() 确实最终运行，但不是在所需的延迟到期之前

事实上，为了验证你为什么不依赖 Timer.schedule(TimerTask task, long delay)指定延迟？

通过这种方式，您可以ClassUnderTest 为接受 a 的测试添加一个构造函数，Timer并且您可以在单元测试期间模拟它。要断言Timer执行它的设计目的，您只需验证是否使用正确的参数调用了模拟，尤其是延迟参数。

@Mock

Timer mockedTimer;

@Test

void constructor(){

   long expectedDelay = ...;

   ClassUnderTest objectUnderTest = new ClassUnderTest(..., mockedTimer);

   Mockito.verify(mockedTimer).schedule(Mockito.any(),  expectedDelay);

}