Java testing: speed up timeout checking time?

Question

I have an application that controls the turns in the game, it is quite complicated, and it has many timers that generate timeouts. Because they interact a lot, it’s hard to be sure that everything is working correctly (and continues to work correctly).

I would like to test it, but some timeouts take several minutes to fully test it, it will take at least one hour!

Is there a way to fake accelerated time for timers? Or should I just scale all the timeouts proportionally down, test them and scale them every time?

thanks!

Answer 1

The way to do this is to create a custom interface that provides a thin shell around the Timer . Then you program across the entire interface in your code. After that, you perform two implementations of the interface. The first is the expected implementation, which connects to the real Timer object, as it is at present. The other is the one you can use for testing. In this implementation, you mock the functionality of Timer , but you have full control over how events are fired and how much time they take. You can scale the duration as suggested by @aioobe, or you could create a backup queue that could fire events quickly so that no time is wasted.

The fact is that you do not need to make changes to this code and use the Injection of Dependency to make the changes necessary for testing.

Answer 2

As far as I know, there is no way to globally scale the speed of Java timers. (Assuming they rely on the System.currentTimeMillis method, you might try to add your own bootclasspath and override this implementation with something else, but this is a complex business for sure (if possible).

I suggest you add the TIME_SCALING factor before the periods and frequencies used for debugging purposes.

 // ... long period = (long) (someValue / TIME_SCALING); // ... // ... double frequency = someValue * TIME_SCALING; // ... 

Answer 3

relying on timer ticks that happen at the right time is prone to difficult traces and rare errors

I would suggest using locks, barriers, semaphores, etc. guarantee - up to a relationship for everything; this requires more interaction between classes, but is more bulletproof (and allows the program to work faster when tested using only one timer if it goes too fast)

Answer 4

Perhaps you can simply simulate the effects of a timer exiting from it and check the status of the application based on this. This would not help to check the timers, but it would be a way to check their effects.

Answer 5

I thought of a simple way .. It’s unpleasant, maybe, but still .. I can do as aioobe (TIME_SCALING) said, leave it closed in the class, and then access it from the tests using reflection .. in this way at least it cannot be seen or used by other classes.

Answer 6

I did something in the same vein, but was thinking about slowing down the JVM by messing around with the internal components of Hotspot. It is not so difficult, but it can introduce subtle errors if it is not done correctly. In any case, I asked a question by asking something along these lines, and someone came up with the idea of ​​starting a virtual machine in VirtualBox and slowing down the time (in my case, to get extra processor time). Perhaps you could speed up the time in your case by reducing the processor time, but ending the tests earlier. Or maybe a precision limit for a timer, or VirtualBox can only slow down time .. hmm.

Answer 7

I am not a developer, but I am also looking for an answer to this question.

In my case, users make transactions in real time, involving various services that have their own time, so the whole transaction process can take several days. Which I can’t imagine that it can only be tested until it is deployed to production to find out that it does not work.

Therefore, I’m looking for a way to simulate my different services with their own time, and, say, for example, an hour can be considered a day so that I can run an accelerated script and complete my transaction in a testing environment without the need for deployment to production.

thanks