java 测试：加速测试超时的时间？答案

【问题标题】：java testing: accelerate time to test timeouts?java 测试：加速测试超时的时间？
【发布时间】：2011-05-12 20:25:16
【问题描述】：

我有一个管理游戏回合的应用程序，它相当复杂，而且它有很多会产生超时的计时器。由于它们经常互操作，因此很难确保一切正常（并保持正常工作）。

我想测试它，但某些超时是几分钟，要完全测试它至少需要一个小时！！

有没有办法为计时器伪造一个加速时间？还是我应该按比例缩小所有超时，测试它们，然后每次都再次放大它们？

谢谢！

【问题讨论】：

请注意：对于如此长时间运行的测试，您可能需要查看 Jenkins 等持续集成系统，以便在每次提交后在后台运行测试。这样，您可以仅针对您在桌面上所做的更改运行一小组测试，并且仍然依靠您的全套测试来使用 CI 进行全面测试。当 CI 中的测试失败时，您会收到通知，但不必每次都自己运行全套测试。
当某些事情超时时会发生什么以及如何检测它？例如，如果您说“它会轮询以查看计时器是否已过期”或“计时器已过期并生成一个传递给感兴趣的听众的事件”，那么您的 Q 的答案可能会完全不同。
定时器产生可见的结果，测试不需要轮询，实际上测试中没有引用定时器..

标签： java testing junit junit4

【解决方案1】：

实现此目的的一种方法是制作您自己的界面，为Timer 提供一个薄包装。然后，您可以在代码中的任何地方对接口进行编程。之后，您对接口进行了两次实现。第一个是预期的实现，它连接到一个真实的Timer 对象，就像你现在拥有的一样。另一种是可用于测试的。在这个实现中，您模拟了Timer 的功能，但您可以完全控制事件的触发方式以及它们需要多长时间。您可以按照@aioobe 的建议调整持续时间，也可以创建一个可以快速触发事件的后备队列，以免浪费时间。

关键是您不必对真实代码进行更改，而是使用Dependency Injection 进行测试所需的更改。

【讨论】：

不错的方法.. 模拟计时器应该放在测试中，对吧？这样它就不会弄乱代码..
依赖注入是测试驱动开发的盟友！
@luca：正确。例如，这里是一个使用Google Guice 的基本示例。您将在最后一个代码块中看到它如何知道它正在请求的接口，但返回的实现取决于用于创建注入器的模型。

【解决方案2】：

据我所知，无法对 Java 计时器的速度进行全局缩放。（假设他们依赖System.currentTimeMillis 方法，您也许可以尝试添加自己的引导类路径并用不同的东西覆盖这个实现，但这肯定是一件棘手的事情（如果可能的话）。）

我建议您在用于调试目的的周期和频率前面添加一个TIME_SCALING 因子。

// ...
long period = (long) (someValue / TIME_SCALING);
// ...

// ...
double frequency = someValue * TIME_SCALING;
// ...

【讨论】：

【解决方案3】：

依赖于在正确的时间发生的计时器滴答声容易出现难以追踪和罕见的错误

我建议使用锁、屏障、信号量等。保证一切的事前发生关系；这需要类之间的更多交互，但更防弹（并且如果程序运行得太快，只需要一个计时器就可以让程序在测试中运行得更快）

【讨论】：

【解决方案4】：

也许您可以只模拟计时器关闭的效果，并据此检查应用程序的状态。它无助于测试计时器，但它是测试其效果的一种方式。

【讨论】：

【解决方案5】：

我想到了一个简单的方法..也许不太好，但仍然..我可以按照 aioobe 所说的（TIME_SCALING）将其保留在课堂上，然后使用反射从测试中访问它..至少这样它不能被其他类看到或使用..

【讨论】：

【解决方案6】：

我在做同样的事情，但考虑通过弄乱 Hotspot 的内部来降低 JVM 的速度。这并不难，但如果做得不好，它可能会引入微妙的错误。无论如何，我在这里发布了一个问题，询问了一些类似的问题，有人提出了在 VirtualBox 中运行虚拟机并减慢时间（在我的情况下，以获得额外的 CPU 时间）的想法。也许您可以加快时间，减少 CPU 时间，但让测试更早完成。或者计时器有精度限制，或者 VirtualBox 只能减慢时间.. 嗯。

【讨论】：