>>> 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.

> 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.

Reply via email to