这是我想要测试的方法:
void someMethodThatRetries(){
Failsafe.with( retryPolicy ).get(() -> callServiceX());
}
重试策略如下所示:
this.retryPolicy = new RetryPolicy()
.retryIf( responseFromServiceXIsInvalid() )
.withBackoff( delay, MAX_DELAY, TimeUnit.MILLISECONDS )
此方法调用服务 X,并在特定条件下重试对服务 X 的调用(来自 X 的响应没有特定值)。每次重试都带有延迟和退避。 测试看起来像这样:
@Test
public void retriesAtMostThreeTimesIfResponseIsInvalid() throws Exception {
// Code that verifies that ServiceX got called 3 times. Service is called using a stub, and I am verifying on that stub
}
我正在编写一个测试,用于验证在满足条件时调用服务 X 3 次(允许的最大重试次数为 3)。
由于延迟和退避,单元测试花费的时间太多。在这种情况下,我们应该如何编写测试?
我想到的一个解决方案是对 RetryPolicy 进行单独的测试,它应该重试 3 次,并对它在满足条件时重试的事实进行单独的测试。
我应该怎么做?
我想说你应该以单元测试callServiceX
和responseFromServiceXIsInvalid
函数为目标,但除此之外,你还处于集成测试和子系统测试(又名组件测试)的领域。 这里所有具有算法性质的东西都隐藏在FailSafe
和RetryPolicy
类和方法后面 - 你的代码只是调用它们。
因此,您的代码可能包含的许多错误在于与这些外部类的交互/正确使用。 例如,您可能弄乱了参数delay
和MAX_DELAY
的顺序 - 只有在集成测试中才会发现这一点。
在单元测试级别上也存在潜在的错误,例如,delay
的值可能与指定的时间单位不匹配。 在我看来,在这种情况下通过单元测试来检查这一点的麻烦太大了。 在重新视图中检查这一点,或者再次使用子系统测试来查看持续时间是否符合预期。
一些额外的警告:在进行集成测试和子系统测试时,请务必将重点放在要查找的错误上。 这将帮助您避免最终有效地测试 FailSafe 和 RetryPolicy 类 - 希望这些类已经被库开发人员测试过。