Redefine: Testing AMD Modules Without A Loader

177 views
Skip to first unread message

Jakob Heuser

unread,
Oct 29, 2013, 7:39:41 PM10/29/13
to amd-im...@googlegroups.com
In the process of rolling out more AMD support at LinkedIn, we found that most testing patterns depended on the loader system being present in order for the global define() variable to work as expected. Shimming define() using a library like sinon.js got us partway there, but we wanted to have a more Chai style way of writing these things. For these reasons, we threw together Redefine.
Temporary Project Page: https://github.com/jakobo/redefine

I'd like to solicit feedback from the group about this testing strategy. We want to ensure our unit tests depend on as little code as possible, including build and download steps. This seemed like an effective way to manage the dependency tree while still keeping a small footprint.

A big hat tip to Squire, which was what we started with internally during our experiments.

Regards,
Jakob

James Burke

unread,
Nov 17, 2013, 8:41:49 PM11/17/13
to amd-im...@googlegroups.com
I'm OK with using a module loader even in tests. Once modules are in
the language, I think it makes sense anyway. And if a test framework
cannot handle async wiring via a module loader, it will lose
marketshare once ES modules are available.

However I do understand wanting to mock or modify modules for test purposes.

In the Firefox OS Gaia clock app, there is a testRequire that allows
loading modules, but pointing to some mocks, and the
multiversion/context capability in requirejs-family loaders is used to
isolate the module tests:

https://github.com/mozilla-b2g/gaia/blob/master/apps/clock/test/unit/test_require.js#L41

Usage:

https://github.com/mozilla-b2g/gaia/blob/master/apps/clock/test/unit/picker/picker_test.js#L9

Thanks for sharing the redefine though, I can see it working for the
use case that triggered its design. It is great to have options in
this area.

James

[1] http://requirejs.org/docs/api.html#multiversion
> --
> You received this message because you are subscribed to the Google Groups
> "amd-implement" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to amd-implemen...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

Jakob Heuser

unread,
Nov 19, 2013, 11:36:32 PM11/19/13
to amd-im...@googlegroups.com
Thanks James. I think helping people understand how to test and mock their dependencies is really important as projects grow in scope. Having multiple patterns (Squire, Redefine, testRequire) will help people get to the level of testing they need.

For those that come across this thread at a later point, here's the known unit testing "friends of AMD"

And here's some node.js concepts that grapple with the similar problems we're discussing

Would this kind of stuff be a good candidate for the AMD wiki?


--Jakob


You received this message because you are subscribed to a topic in the Google Groups "amd-implement" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/amd-implement/4Uu-hweOJC4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to amd-implemen...@googlegroups.com.

James Burke

unread,
Nov 20, 2013, 12:58:41 AM11/20/13
to amd-im...@googlegroups.com
On Tue, Nov 19, 2013 at 8:36 PM, Jakob Heuser <ja...@felocity.com> wrote:
> Thanks James. I think helping people understand how to test and mock their
> dependencies is really important as projects grow in scope. Having multiple
> patterns (Squire, Redefine, testRequire) will help people get to the level
> of testing they need.
>
> For those that come across this thread at a later point, here's the known
> unit testing "friends of AMD"
> * squire: https://github.com/iammerrick/Squire.js/
> * redefine: https://github.com/jakobo/redefine
> * testRequire:
> https://github.com/mozilla-b2g/gaia/blob/master/apps/clock/test/unit/test_require.js
>
> And here's some node.js concepts that grapple with the similar problems
> we're discussing
> * rewire: https://github.com/jhnns/rewire
> * proxyquire: https://npmjs.org/package/proxyquire
> * a: https://npmjs.org/package/a
> * mockery: https://npmjs.org/package/mockery
>
> Would this kind of stuff be a good candidate for the AMD wiki?

Great collection of links, yes please feel free to add to the wiki!

James
Reply all
Reply to author
Forward
0 new messages