Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

MockDOMRequest and removing setTimeout() from tests

15 views
Skip to first unread message

Tim Chien

unread,
Mar 25, 2014, 6:08:36 AM3/25/14
to dev-...@lists.mozilla.org
Hi all,

I've just land a MockDOMRequest in the shared script and fix some of the tests.
https://bugzilla.mozilla.org/show_bug.cgi?id=974319

With MockDOMRequest, you are given explicit control over the mocked
async API. The test will run faster too.

I will spend time identify more tests to be fixed. In the mean time
please stop checking-in new tests/mock with setTimeout().

Thanks,


--
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)

Julien Wajsberg

unread,
Mar 25, 2014, 10:48:34 AM3/25/14
to Tim Chien, dev-...@lists.mozilla.org
Le 25/03/2014 11:08, Tim Chien a écrit :
> Hi all,
>
> I've just land a MockDOMRequest in the shared script and fix some of the tests.
> https://bugzilla.mozilla.org/show_bug.cgi?id=974319
>
> With MockDOMRequest, you are given explicit control over the mocked
> async API. The test will run faster too.
>
> I will spend time identify more tests to be fixed. In the mean time
> please stop checking-in new tests/mock with setTimeout().
>
>

While I agree with the goal (remove setTimeouts we have in some mocks...
some are my fault), isn't it possible to simply use a really minimal
mock interface and use sinon in tests to give it behavior?

For example, in a test we could spy addEventListener, and call
"spy.yield" to simulate an event.

I'm not very comfortable with having complex mocks (I know I made some
of them... but I learnt more since then).
--
Julien

signature.asc

Tim Chien

unread,
Mar 26, 2014, 10:03:10 AM3/26/14
to Julien Wajsberg, dev-...@lists.mozilla.org
Partly agree. Yes, we shouldn't write complex mocks, but DOMRequest
(or more specifically, EventTarget) are not that complex. We also
don't need to patch the mock frequently because these interfaces are
stable fixture of the web.

The one thing complex enough for us not to write complete mocks is the
InputMethod API; I know that because I spent hours writing a mock with
it's own state control in
https://bugzilla.mozilla.org/show_bug.cgi?id=987533 and I feel I am
re-implementing the API itself...

I will remove the states and simply returns noop Promises on the methods.
0 new messages