I didn't say unit test. If you want to stick a name on what I am saying, it's just classic ports and adapters http://c2.com/cgi/wiki?PortsAndAdaptersArchitecture
In your example, shifting it to the 'fs' sample, you'd be saying "write tests against 'fs' to make sure you know how it works" - but that's not a good use of time or energy, you're best of writing tests on the adapter that *uses* 'fs' to make sure your assumptions of how fs works are valid - it's a subtle difference, but an important one. You can then run those tests against an in memory version of your adapter, which you can make available for the rest of your tests - easily being able to switch these things around has a lot of value in some cases. And just to be a pedant, use of a container in C# is how *some *folk in that world do dependency injection, some of us shy away from that and build up our object graphs manually and organically. On a side note I think we should be careful in this kind of conversation (if we're even going to have it) to separate the needs of testing, the needs of extensibility - and what we call dependency injection, dependency inversion and inversion of control containers. On Sun, Jul 29, 2012 at 2:12 PM, [email protected] < [email protected]> wrote: > The problem basically comes down to being able to mock/stub out the > require module system, I am yet to see a nice simple way of doing it (if > you have one please let me know!). This is solved in other languages like > C# which uses Dependency injection with a container but in ruby you don't > need to inject dependencies as its possible to directly mock things out (if > I remember correctly). So DI is not it is not necessarily the best > technique for javascript. > > @Oliver Leics that looks a bit like how > node-sandboxed<https://github.com/felixge/node-sandboxed-module> > works > > @Rob Ashton For a unit test I don't really want to be hitting an > external environment. A good example is if you make a http call to another > api, at the unit test level you just want to make sure you are hitting the > right url with the correct data. You can then write an integration test > against this api to make sure you know how it behaves. > > > On Saturday, July 28, 2012 10:26:59 AM UTC+1, Rob Ashton wrote: >> >> Well, I think if you're writing code against fs, you should test against >> fs >> >> If you want the rest of your tests to go fast, you should fake out the >> bit which uses fs, not fs itself >> >> Speaking in a general tone anyway, more context required for specific >> scenarios >> >> Sent from my iPhone >> >> On 28 Jul 2012, at 09:02, Eldar <[email protected]> wrote: >> >> Thank you for pointing to Broadway. >> >> But yeah there are situations where hooks were not planed. For example: >> >> Once I tried to mock the file system. The goal were to define directory >> layout right in test. That's much more better and cleaner then having >> separate fixtures dir created by hand. You have all information right were >> it used, you have instant understanding of what's going on, etc. But you >> can't mock file system if you need real IO right in the test and at the >> same time you are using third party! Anyway, even if you don't have such >> case, isn't it better to just use "require" for things that semantically >> are nothing more then just a "require", rather then introduce artificial >> hooks? >> >> That's the reason why I'd like such thing to be officially supported. >> Actually the title of the topic is wrong. I had in mind feedback >> for proposal. >> >> On Saturday, July 28, 2012 2:02:05 AM UTC+4, Marak Squires wrote: >>> >>> Yeah, that's pretty much the whole point of Broadway. >>> >>> I use Broadway a lot of "plugin systems". Essentially, where you are >>> requiring files as node.js modules, but you want programmatic hooks into >>> the initialization and attachment process of the module. >>> >>> On Fri, Jul 27, 2012 at 2:57 PM, Joshua Holbrook < >>> [email protected]> wrote: >>> >>>> You might like this, Eldar: >>>> >>>> https://github.com/flatiron/**broadway<https://github.com/flatiron/broadway> >>>> >>>> It gives you dependency injection and IoC. We use it a lot in >>>> flatiron, it's pretty sweet. >>>> >>>> --Josh >>>> >>>> On Fri, Jul 27, 2012 at 2:27 PM, Rob Ashton >>>> <[email protected]> wrote: >>>> > Yeah, sorry >>>> > >>>> > Not a real developer, never worked on a real project, excuse me for my >>>> > ignorance. >>>> > >>>> > Lol jking >>>> > >>>> > Sigh >>>> > >>>> > Sent from my iPhone >>>> > >>>> > On 27 Jul 2012, at 20:33, Joe Developer <[email protected]> >>>> wrote: >>>> > >>>> > Erm, outside of the amateur hour projects just such functionality >>>> exists: >>>> > http://blog.endpoint.com/2011/**02/locally-served-yui3.html<http://blog.endpoint.com/2011/02/locally-served-yui3.html> >>>> > >>>> > And yes, once you have had the pleasure of using it on non-trivial >>>> apps you >>>> > miss it dearly when dealing with the ad-hoc structured or 'good enough >>>> > rolled' alternatives. >>>> > >>>> > On Fri, Jul 27, 2012 at 11:47 PM, Martin Cooper <[email protected]> >>>> wrote: >>>> >> >>>> >> On Fri, Jul 27, 2012 at 8:07 AM, Rob Ashton <[email protected] >>>> > >>>> >> wrote: >>>> >> > Do we need dependency injection in nodejs? Well - if you mean >>>> dependency >>>> >> > injection literally, we have it already, it looks like this >>>> >> > >>>> >> > function doSomething(dependency) { >>>> >> > >>>> >> > } >>>> >> > >>>> >> > doSomething(new FooDependency()) >>>> >> > >>>> >> > or >>>> >> > >>>> >> > doSomething(new BarDependency()) >>>> >> > >>>> >> > or >>>> >> > >>>> >> > var Animal = function(vocals) { >>>> >> > this.vocals = vocals >>>> >> > } >>>> >> > >>>> >> > var cat = new Animal(miaow) >>>> >> > cat dog = new Animal(woof) >>>> >> > >>>> >> > etc >>>> >> > >>>> >> > ---------- >>>> >> > >>>> >> > If you're talking about 'container' support to support this, it's >>>> a >>>> >> > road >>>> >> > that has been trodden well by .NET and Java devs, and has been >>>> shown >>>> >> > time >>>> >> > and time again to lead full circle to the very beginning where you >>>> just >>>> >> > build your object graphs manually and introduce extensibility >>>> points >>>> >> > where >>>> >> > you need them for either mocking out slow dependencies for testing >>>> or >>>> >> > allowing consumers to control something about your code. >>>> >> > >>>> >> > Trying to bake in support to this as part of the require system >>>> seems >>>> >> > like >>>> >> > asking for trouble, keep it explicit, keep it as needed and let the >>>> >> > goodness >>>> >> > follow. >>>> >> >>>> >> I agree with this. If you need dependency injection, design it into >>>> >> your system. Don't force it on unsuspecting modules. >>>> >> >>>> >> A couple of things that come to mind off the top of my head: >>>> >> >>>> >> * If I compel some module to use, say, 'my-funky-fs' instead of 'fs' >>>> >> without knowing it, will that cause *its* dependencies to have their >>>> >> usage of 'fs' replaced too? What if one of them was already replacing >>>> >> it with something of its own choosing, perhaps using a different >>>> >> mechanism (like maybe graceful-fs)? >>>> >> >>>> >> * If someone reports an issue with one of my packages, and I spend a >>>> >> bunch of my time debugging it, only to discover that the reporter >>>> >> replaced one of my dependencies with some other flaky substitute and >>>> >> that's the culprit, I'm not going to be happy about that. I design my >>>> >> packages to work with their declared dependencies, or I specifically >>>> >> design for dependency injection if it's needed. >>>> >> >>>> >> > My two cents. >>>> >> >>>> >> And mine. :) >>>> >> >>>> >> -- >>>> >> Martin Cooper >>>> >> >>>> >> >>>> >> > On Fri, Jul 27, 2012 at 4:45 PM, Eldar <[email protected]> wrote: >>>> >> >> >>>> >> >> Do we need this in Node? >>>> >> >> >>>> >> >> My answer is yes we need some (simple) way to specify the app >>>> level >>>> >> >> dependencies at runtime. Here is my take on this. Please >>>> checkout and >>>> >> >> let >>>> >> >> me know how do you feel about. >>>> >> >> >>>> >> >> But the idea is very simple: >>>> >> >> >>>> >> >> >>>> >> >> // inside any index.js >>>> >> >> var R = require('runtime').**patchNative() >>>> >> >> var use = R(module).use >>>> >> >> >>>> >> >> use('fs', 'node_modules/third/party', require('./smart-fs')) >>>> >> >> >>>> >> >> That's it. Third party module just uses our smart file system >>>> >> >> >>>> >> >> -- >>>> >> >> Job Board: http://jobs.nodejs.org/ >>>> >> >> Posting guidelines: >>>> >> >> https://github.com/joyent/**node/wiki/Mailing-List-** >>>> 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 >>>> >> >> nodejs+unsubscribe@**googlegroups.com<nodejs%[email protected]> >>>> >> >> For more options, visit this group at >>>> >> >> http://groups.google.com/**group/nodejs?hl=en?hl=en<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<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 >>>> >> > nodejs+unsubscribe@**googlegroups.com<nodejs%[email protected]> >>>> >> > For more options, visit this group at >>>> >> > http://groups.google.com/**group/nodejs?hl=en?hl=en<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<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 >>>> >> nodejs+unsubscribe@**googlegroups.com<nodejs%[email protected]> >>>> >> For more options, visit this group at >>>> >> http://groups.google.com/**group/nodejs?hl=en?hl=en<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<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 >>>> > nodejs+unsubscribe@**googlegroups.com<nodejs%[email protected]> >>>> > For more options, visit this group at >>>> > http://groups.google.com/**group/nodejs?hl=en?hl=en<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<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 >>>> > nodejs+unsubscribe@**googlegroups.com<nodejs%[email protected]> >>>> > For more options, visit this group at >>>> > http://groups.google.com/**group/nodejs?hl=en?hl=en<http://groups.google.com/group/nodejs?hl=en?hl=en> >>>> >>>> >>>> >>>> -- >>>> Joshua Holbrook >>>> Head of Support >>>> Nodejitsu Inc. >>>> [email protected] >>>> >>>> -- >>>> Job Board: http://jobs.nodejs.org/ >>>> Posting guidelines: https://github.com/joyent/**node/wiki/Mailing-List- >>>> **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 >>>> nodejs+unsubscribe@**googlegroups.com<nodejs%[email protected]> >>>> For more options, visit this group at >>>> http://groups.google.com/**group/nodejs?hl=en?hl=en<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<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 >> nodejs+unsubscribe@**googlegroups.com<[email protected]> >> For more options, visit this group at >> http://groups.google.com/**group/nodejs?hl=en?hl=en<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
