Le 17/12/2013 14:06, Dale Harvey a écrit : > Investigating some unit test failures I am seeing a lot of setTimeout's > located inside the tests, someone already made a meme for me for the > occasion > > http://mozillamemes.tumblr.com/post/24322890551/now-if-you-add-an-event-listener-that-sets-a > > More specifically everyone is gonna have a bad time because we will have > buggy intermittent tests and closed trees, just a reminder for coders and > more specifically reviewers that setTimeouts should pretty much only be > used to yield / spin the event loop inside tests, not for any form of timer > / waiting solution >
What I learnt for 1 year is that setTimeout should _never_ be used in tests. Tests should _never_ be asynchronous. If you use setTimeout in code, then use sinon's fake timers to linearize this code and make it synchronous. I recently rewrote the tests for system's keyboard manager in [1] (still pending review, wink wink) and the previous tests used another bad pattern: it injected CSS containing transformations and transitions so that the code got the "transitionend" events. This is much like setTimeout: waiting that something asynchronous is happening. I rewrote this by sending the transitionend event in the test itself, which reliably triggers the event in a synchronous way, and make it way faster in the same time. The only situation where an asynchronous test was needed was testing indexedDB code. I don't think we want to mock the indexedDB code to make it synchronous here. I could still change my mind though ;) So we increased mocha's timeout a lot, and we expect to have some rare intermittent with this code. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=936369 -- Julien
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
