Add Support for dependency injection

[jsdevel]

It would be really nice to support dependency injection. On the command line, you could add a flag for a provider module path. In a browser you could load a provider before your test scripts. It would probably look like angular's factory pattern.

mocha.factory('someDep', function(){return a;});

//later in my test
describe(function(someDep){
//tests here
});

[jsdevel]

Would this be a welcomed addition if I were to submit a pull request for review?

[rlidwka]

what's wrong with require and a bunch of other module loaders?

[jsdevel]

Redundancy. Plus if I ever want to change the location of one of my modules I have to change it all over my entire project.

[tj]

you could just use NODE_PATH and give the test modules precedence, or hack require(), definitely not something that should be in mocha IMO

[travisjeffery]

i'm -1 too. enough to be a whole separate lib or something.

[rlidwka]

you could just use NODE_PATH and give the test modules precedence

That's something discouraged afair.

@jsdevel, but yeah, you can use other dependency injection libraries with mocha or write your own. Not suggesting to copy angular decisions (it's turned out to be really bad library after all), but some amd.js loaders can help you with that task.

[jsdevel]

Thanks for the discussion guys! Nothing popped up on NPM. I can see the wisdom in keeping it in a separate lib.

@rlidwka Why do you think angular is bad?

[rlidwka]

Why do you think angular is bad?

I have no love for client-side only frameworks, because they are slow and don't work in browsers where javascript is turned off.

But AngularJS deserves a special attention because it's what is usually called "insecure by design" (here's nice write-up). Template engine where code and content aren't strictly separated is definitely not a good one.

[ORESoftware]

DI would be a good replacement for the current --delay functionality which is hacky, no?

[jsdevel]

I could see DI saving a lot of reuiqre('../../../../bla') in tests though, considering that you could wire up mocks globally with DI.

it('should do something asynchronously', function(done, myDbMock) {
  sut(myDbMock).should.eventually.equal(/* user object */).and.notify(done);
});`

[ORESoftware]

yeah...saving require verbiage is not so useful, but I think if you could replace the --delay option (see mocha homepage) with DI/IoC that would very cool. The difference being the DI would inject dependencies that were sourced/initialized asynchronously. Basically, you could "require" dependencies that can be loaded synchronously, but any dependency that needs some asynchronous setup, could be loaded with DI. The only reason to do this, is for dynamic test cases. Meaning, a dynamic number of it()s, which currently is only possible using --delay. There is an open issue for this as of early Feb 2016.