<AWT Dev> [9] Review Request: 8177841 Some java/awt/Robot tests can be improved

[Semyon Sadetsky]

On 04/10/2017 09:20 PM, Sergey Bylokhov wrote:
>
>> 10 апр. 2017 г., в 18:18, Semyon Sadetsky <semyon.sadetsky at oracle.com 
>> <mailto:semyon.sadetsky at oracle.com>> написал(а):
>>
>> On 04/10/2017 06:15 AM, Sergey Bylokhov wrote:
>>
>>>>>>>
>>>>>>> We already have a mechanism which kills the tests after timeout, 
>>>>>>> we also have a default timeout of 2 minutes.
>>>>>>> I am not sure how to get dump of all threads from the catch block.
>>>>>> But shouldn't the time frame when a mouse click may come be 
>>>>>> limited? Will it be correct when the click triggered after 2 
>>>>>> minutes delay makes the test passed anyway?
>>>>>
>>>>> If timeout will occur and the test still was not complete, then it 
>>>>> will be killed, all frames will be closed, the dump of all threads 
>>>>> will be generated. So the test cannot pass after timeout.
>>>> I meant when the listener is triggered right before the 2 minutes 
>>>> timeout, for example in 1 minute 59 seconds. In the current logic 
>>>> the test passes in this case and no dumps were generated for any 
>>>> thread. But actually this means an issue because event shouldn't be 
>>>> delayed for that amount of time or this event is not generated by 
>>>> the test.
>>>
>>> If the test will complete successfully before timeout then it will 
>>> validate the functionality which it was targeted for. The slowness 
>>> can be from the slow/embedded system, or if the system was 
>>> overloaded by some other tasks. If the test will fails on such 
>>> systems by the timeout then the user will be able to tweak it via 
>>> jtreg parameter.
>> 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).
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170411/b061b184/attachment.html>