Oh, and apologies to everybody that I even linked to a GoF related article
on a node mailing list, I'll try not to do this again in the near future.

On Sun, Jul 29, 2012 at 2:36 PM, Rob Ashton <[email protected]> wrote:

> And I don't think the problem boils down to stubbing out the require
> system, the problem boils down to writing code that specifically opens
> itself up to testing and extension - 'Broadway' is an example of how to do
> this.
>
> 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

Reply via email to