[ANN] Mockery - hooking 'require' to simplify the use of mocks

457 views
Skip to first unread message

Martin Cooper

unread,
Oct 14, 2011, 11:49:02 AM10/14/11
to nod...@googlegroups.com
To unit test your modules, you need to mock out their dependencies. In
Node, that means you want 'require' to hand back a mock instead of the
dependent module. But properly hooking 'require' isn't as easy, or as
obvious, as it might be.

Mockery wraps a simple API around the hooking of 'require', to let you
provide mocks or substitute whole modules.

The job of Mockery is only hooking 'require' so you don't have to.
Thus you're free to use any (or no) mocking framework with Mockery,
and it's use is in no way limited to unit testing with mocks. If you
need to hook 'require' for some other purpose, Mockery will do the
job.

Read more at:

https://github.com/mfncooper/mockery

--
Martin Cooper

Bryan Donovan

unread,
Oct 16, 2011, 8:44:51 PM10/16/11
to nod...@googlegroups.com
Martin,

This is excellent stuff! Thanks for releasing it. It's the first tool I've been able to get working reliably for mocks. I've run into limitations with Gently and other libraries, but Mockery just works. Combined with Sinon, I finally have a usable mocking/stubbing setup that doesn't make me want to gouge my eyes out.


Regards,

Bryan

> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

Felix Geisendörfer

unread,
Oct 17, 2011, 11:44:17 AM10/17/11
to nod...@googlegroups.com
Having battled this problem for a while myself, here is my solution which does the same except that it only manipulates the require function of the included module which should be less confusing:

https://github.com/felixge/node-sandboxed-module

Martin Cooper

unread,
Oct 18, 2011, 11:29:00 PM10/18/11
to nod...@googlegroups.com
On Sun, Oct 16, 2011 at 5:44 PM, Bryan Donovan <brdo...@gmail.com> wrote:
> Martin,
>
> This is excellent stuff! Thanks for releasing it.  It's the first tool I've been able to get working reliably for mocks.  I've run into limitations with Gently and other libraries, but Mockery just works.  Combined with Sinon, I finally have a usable mocking/stubbing setup that doesn't make me want to gouge my eyes out.
>

I didn't expect to be saving someone's eyesight by creating this, but
I'm glad to hear it's helpful. :-)

--
Martin Cooper

Martin Cooper

unread,
Oct 18, 2011, 11:29:07 PM10/18/11
to nod...@googlegroups.com
2011/10/17 Felix Geisendörfer <haim...@gmail.com>:

I did look at this, amongst others, before creating Mockery, and there
were a few things that I wanted to do differently. Easily handling
"nested" requires was one of them; if my source under test uses
rimraf, for example, I might want to just mock fs, and not rimraf per
se. Another was easily identifying the modules that are *not* mocked,
so that I'm always aware of anything my source under test is using
that it perhaps should not be using in a true unit test.

To each his own, though. While the two packages overlap in
functionality, I think each addresses a slightly different set of use
cases. I like that about the Node community; sharing ideas expressed
in packages, and avoiding the trappings of "one size fits all".

Felix Geisendörfer

unread,
Oct 20, 2011, 1:50:17 AM10/20/11
to nod...@googlegroups.com
On Wednesday, 19 October 2011 05:29:07 UTC+2, Martin Cooper wrote:

I did look at this, amongst others, before creating Mockery, and there
were a few things that I wanted to do differently. Easily handling
"nested" requires was one of them; if my source under test uses
rimraf, for example, I might want to just mock fs, and not rimraf per
se.

Good point. I explicitly decided that I did not want that. I think mocking the collaborators of a class directly is much better than mocking their internal implementation details.
 

To each his own, though. While the two packages overlap in

functionality, I think each addresses a slightly different set of use
cases. I like that about the Node community; sharing ideas expressed
in packages, and avoiding the trappings of "one size fits all".


Agreed. Your module looks great. Thanks for the work : ).

--fg 
Reply all
Reply to author
Forward
0 new messages