Le 18/12/2013 19:49, James Burke a écrit : > On Wed, Dec 18, 2013 at 8:10 AM, Julien Wajsberg <[email protected]> > wrote: >> The main issue is that using setTimeout or other async tests on Travis >> and TBPL will always trigger intermittent from time to time because it >> will hit the max timeout for a test. >> >> So sometimes we can't avoid it, and in that case we should augment the >> expected timeout, but we should try hard to not use async tests if it's >> possible. > Switching code that usually expects async operation to go sync can > open up bugs of its own, and they are very subtle, hard to catch and > debug[1]. Unfortunately I know that from previous experience.
You can move to "sync" test in an async-like way. For a code that runs like this: code A asyncMethod(callback) code B What happens in real life is : code A code B ... some time callback What should happen in test is: code A code B ... simulate time callback What should _not_ happen in test is: code A callback code B And I think this is what you meant by "Switching code that usually expects async operation to go sync can open up bugs of its own", and I agree. The microtask and the queue is essentially what I suggest too. This is usually already easy to do manually, and this is probably still easier with promises that calls the callback at the end of the queue without waiting for an unreliable timeout. So I guess we all agree here :) Using setTimeout to guess the completion of an async operation is really really bad, but the intermittents I see are usually more "setTimeout does not trigger before mocha is timing out". -- Julien
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
