java测试：加速测试超时时间？
我有一个管理游戏回合的应用程序，它相当复杂，并且有很多生成超时的计时器..由于它们交互操作很多，因此很难确保一切正常工作（并保持正常工作）。
我想测试一下，但是某些超时是几分钟，要完全测试它至少需要一个小时！
有没有办法伪造计时器的加速时间？或者我应该按比例缩小所有超时，测试它们，然后每次再次扩大它们？
谢谢！
I have an app that manages turns in a game, it's fairly complex and it has a lot of timers that generate timeouts.. since they interoperate a lot it's difficult to be sure everything's working right (and keeps working right).
I'd like to test it, but certain timeouts are of a few minutes, to test it completely it'd take at least one hour!!
Is there any way to fake an accelerated time for the timers? Or should I just scale all the timeouts proportionally down, test them, and scale them up again each time?
thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
实现此目的的一种方法是创建您自己的界面，为
Timer提供一个薄包装器。然后，您可以在代码中的任何地方针对接口进行编程。之后，您将实现该接口的两个实现。第一个是连接到当前的真实 Timer 对象的预期实现。另一种是可用于测试的。在此实现中，您模拟了计时器的功能，但您可以完全控制事件的触发方式以及事件需要多长时间。您可以按照@aioobe的建议调整持续时间，或者您可以创建一个可以快速触发事件的后备队列，这样就不会浪费时间。关键是您不必更改实际代码并使用 依赖注入 来进行测试所需的更改。
A way to do this would be to make your own interface that provides a thin wrapper around
Timer. You then program towards the interface everywhere in your code. After that, you make two implementations of the interface. The first is the expected implementation that connects to a realTimerobject like you have currently. The other is one that you can use for testing. In this implementation you mock the functionality of aTimer, but you have full control of how the events are triggered and how long they take. You could scale the duration as suggested by @aioobe or you could make a backing queue that could rapidly fire events so that there is no wasted time.The point is that you don't have to make changes to the real code and use Dependency Injection to make changes needed for testing.
据我所知，没有办法对 Java 计时器的速度进行全局扩展。 （假设它们依赖于 System.currentTimeMillis 方法，您也许可以尝试添加自己的 bootclasspath 并用不同的东西覆盖此实现，但这肯定是一件棘手的事情（如果可能的话）。）
我建议您在用于调试目的的周期和频率前面添加一个
TIME_SCALING因子。There is to my knowledge no way to do a global scaling of the speed of the Java Timers. (Assuming they rely on the
System.currentTimeMillismethod, you could perhaps try to add your own bootclasspath and override this implementation with something different, but this is tricky business for sure (if it's even possible).)I suggest you add a
TIME_SCALINGfactor in front of periods and frequencies used for debugging purposes.依赖计时器在正确的时间发生很容易出现难以追踪和罕见的错误，
我建议使用锁、屏障、信号量等。保证一切事情发生之前的关系；这需要类之间有更多的交互，但更安全（并且允许程序在测试中运行得更快，如果运行得太快，则只需要一个计时器）
relying on timer ticks to happen on the right time is prone to difficult to trace and rare bugs
I'd suggest using locks, barriers, semaphores, ect. to guarantee happens-before relations on everything; this requires more interaction between classes but is more bullet proof (and allows the program to run faster in testing with only one timer needed if it goes way too fast)
也许您可以模拟计时器关闭的效果，并据此检查应用程序的状态。它无助于测试计时器，但它是测试其效果的一种方法。
Maybe you can just simulate the effects of a timer going off, and checking the state of the application based on that. It wouldn't help test the timers, but it would be a way to test their effects.
我想到了一个简单的方法..也许不太好，但仍然..我可以像aioobe所说的那样（TIME_SCALING）将其保留在类中，然后使用反射从测试中访问它..这样至少可以'不被其他类看到或使用..
I thought of a simple way.. not nice maybe but still.. I can do as aioobe said (the TIME_SCALING) put keep it private in the class, then access it from the tests using reflection.. this way at least it can't be seen or used by other classes..
我也在做同样的事情，但考虑通过扰乱 Hotspot 的内部结构来减慢 JVM 的速度。这并不难，但如果做得不好，可能会引入微妙的错误。不管怎样，我在这里发布了一个问题，询问了一些类似的问题，有人提出了在 VirtualBox 中运行虚拟机并减慢时间的想法（在我的例子中，是为了获得额外的 CPU 时间）。也许您可以加快您的情况的时间，减少 CPU 时间，但使测试更早完成。或者也许计时器有精度限制，或者 VirtualBox 只能减慢时间.. 嗯。
I was doing something along the same lines, but thinking about slowing down the JVM by messing with the internals of Hotspot. It's not that hard, but it can introduce subtle bugs if not done right. Anyway, I posted a question here asking something along those lines, and someone came up with the idea of running the virtual machine in VirtualBox, and slowing down the time (in my case, to gain extra CPU time). Perhaps you could speed up the time in your case, reducing CPU time, but making tests finish earlier. Or maybe there's a precision limit to the timer, or VirtualBox can only slow down time.. hmm.