First, it's awesome that we're talking about dependency injection.

Second, I believe *good* dependency injection requires inversion of
control<http://en.wikipedia.org/wiki/Inversion_of_control>
.

Your modules should not directly require dependencies if possible, rather
design them to accept their dependencies on startup. A very simple example
is as follows:

https://gist.github.com/4596218

Your top-level module like server.js should *only *wire your application
together. Then a test module can just decide to wire the application using
mocks instead.

I realize replacing node_modules feels cooler as it happens automatically,
but I would probably call this a smell.



On Tue, Jan 22, 2013 at 1:57 AM, José F. Romaniello
<[email protected]>wrote:

> This doesnt work in practice because you might want to use different test
> doubles for different tests, there are several ways to mock module
> dependencies, on option is to use vm.runInNewContext
>
> I did a module for this
>
> https://github.com/jfromaniello/mockuire
>
> it is like commonjs's require, but you can pass dependencies when you
> require a module.
>
> El domingo, 20 de enero de 2013, Athan Clark escribió:
>
> Hello everyone. I'd like to make unit testing a practice difficult to
>> evade in Node.js. One of the requirements, though, is that you need to be
>> able to test a module's functionality independently of it's dependencies
>> (say that 10 times fast!). My idea is to make node more flexible in the
>> directories it chooses to look for node modules by providing an alternative
>> "mode" for it to look in - ie if *NODE_MODE* is set to "test", then npm
>> will first try to look in ./test_node_modules for a package before looking
>> in ./node_modules. That way we can provide *alternative *modules for a
>> package - ie mock ones. Or if you were trying to make a package that was
>> compatible with similar modules, you could have a 3rd party testing
>> package, like a simple blog, that uses the similar package in one mode,
>> then your package in another.
>>
>> Imagine being able to do a *`npm run-scripts test --deep`*, and then see
>> each and every module complete a unit test before progressively walking up
>> the dependance tree making scenario tests along the way. It makes my
>> continuous integration senses salivate.
>>
>> What do you all think? Could someone could direct me to where/how npm /
>> node implements `require();`? Where should I start?
>>
>> Thanks in advance!!
>>
>> --
>> 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 [email protected]
>> To unsubscribe from this group, send email to
>> [email protected]
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>  --
> 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 [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Reply via email to