<AWT Dev>  Review Request: 8177841 Some java/awt/Robot tests can be improved
semyon.sadetsky at oracle.com
Wed Apr 12 15:10:19 UTC 2017
On 04/11/2017 09:06 AM, Sergey Bylokhov wrote:
>>>> Anyway 2 minutes seems a very unusual waiting time for the event at any circumstances. Usually, in the client-libs tests after an action is triggered, we wait for silence in all event queues plus a small period of several hundreds milliseconds. Why in this particular test such huge waiting is necessary?
>>> Usually we wait in the test some amount of time in the common code path, when the test is passed. This "small period of time" usually tweaked for the slow systems, so we could get a situation when the test is executed more than 2 minutes in the common case(when it is passed). Because the «small period of time» is different between common systems and slow/embeded systems. The approach in the current test will work instantly on the fast systems, and will wait till timeout on the slow systems. To summarize we already have timeout handling in the jtreg and should not reinvent it per test.
>> We should keep the general approach. I've never seen fixes that require 2 minutes waiting for an event. 5 seconds waiting would be enough for any platform and for the most heaviest toolkit actions (in the current test you wait for a single mouse button click which is one of the lightest).
> The general approach when we wait some random time(1 or 5 or 10 seconds between an operations) assuming that it is enough of time is incorrect, it is slow down the testing. The changed code will work instantly, and in case of errors provides an additional debug information.
We use Robot::waitForIdle() which monitors queues. If the system is
overloaded it doesn't process the queues and the Robot::waitForIdle()
waits longer. If the queues get stuck for many seconds the
robot.waitForIdle() throws exception and test fails.
>> I see a lot of disadvantages of the new event waiting approach you've introduced. That infinite waiting relying on jtreg timeout may cause unreasonable increase of test execution time. Also, I suppose that the situation when mouse button event comes later than in 5 seconds on any embedded system bears an investigation and the test should fail.
>> It is not a load testing but an usual UI testing and this means an issue if UI doesn't react to mouse click for seconds (not even to mention the minutes...). Imagine yourself as a user of such UI.
More information about the awt-dev