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. For me, it also seems like it is trying to work around a problem in the test infrastructure that ultimately defeats the purpose of the tests: to verify that the code written will perform as expected. If the code written expects async operation, the tests should be async. Although I also appreciate that having a robust test infrastructure is hard, requires dedicated, ongoing resources. For speed concerns, perhaps the microtasks idea may help with that. I am still hazy on them, but it seems like an async callback is called after the current execution via a local queue, not placed at the end of the main event loop. They seem like they will be used behind the scenes, but I have been thinking of using an immediately resolved promise to take advantage of them if/when microtasks and promises are in the platform (and assuming the promise implementation uses them). In any case, I do not want to derail the main message of this thread: do not use setTimeout to guess when an async action is done, listen for an event or publicly observable state to confirm the completion of the async operation instead. [1] http://blog.izs.me/post/59142742143/designing-apis-for-asynchrony _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
