On 12/18/14, 2:28 PM, Nils Ohlmeier wrote:
Well there is an event listener waiting for the event to fire. But how else then through a timeout, obviously with a high timeout value like 30 or 60 seconds
We've had quite a number of random oranges from precisely this scenario. It seems that it's not uncommon for the test VMs to completely lose the timeslice for 60 seconds or more.
If the test is in fact expecting the event to fire, the right thing to do is to jut have the test time out per the harness timeout (which can be globally adjusted as needed depending on the characteristics of the test environment) if the event doesn't fire. Rolling your own shorter timer just means contributing to random orange.
Sure I can print an info message that my test is now waiting for an event to pop,
Sure, and another one when the event comes in. Then you can check the log to see whether the timeout was for this reason in the event of a harness timeout on this test.
But as I tried to describe in my other email having a long living timer which pops complaining that event X is missing I think is a legit use case for setTimeout in test.
Given the number of random oranges we've had from _precisely_ this use of setTimeout, I don't think it's legit.
-Boris _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
