Jacob, We've used this same dependency injection approach in our code with great success, both from a runtime and testing standpoint.
In your example you make the "light dependencies" distinction which we do as well. For me I usually treat modules that expose pure functions (underscore or async) as ones that can be required directly while anything that has side effects or interacts with external resources (databases or file systems) gets passed in. -- Daniel R. <[email protected]> [http://danielr.neophi.com/] On Tue, Jan 22, 2013 at 11:58 AM, Jacob Groundwater <[email protected]>wrote: > 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 > -- 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
