事实上，你可以在没有IoC容器的情况下测试node.js，因为JavaScript是一种真正动态的编程语言，你可以在运行时修改几乎所有东西。

考虑以下几点:

import UserRepository from "./dal/user_repository";

class UserController {
    constructor() {
        this._repository = new UserRepository();
    }
    getUsers() {
        this._repository.getAll();
    }
}

export default UserController;

因此，您可以在运行时覆盖组件之间的耦合。我认为我们应该以解耦JavaScript模块为目标。

实现真正解耦的唯一方法是删除对UserRepository的引用:

class UserController {
    constructor(userRepository) {
        this._repository = userRepository;
    }
    getUsers() {
        this._repository.getAll();
    }
}

export default UserController;

这意味着你需要在其他地方进行对象合成:

import UserRepository from "./dal/user_repository";
import UserController from "./dal/user_controller";

export default new UserController(new UserRepository());

我喜欢将对象组合委托给IoC容器的想法。您可以在文章《JavaScript中依赖倒置的当前状态》中了解更多关于此思想的内容。这篇文章试图揭穿一些“JavaScript IoC容器神话”:

误解1:JavaScript中没有IoC容器的位置 误解2:我们不需要IoC容器，我们已经有模块加载器了! 误解3:依赖倒置===注入依赖

如果你也喜欢使用IoC容器的想法，你可以看看InversifyJS。最新版本(2.0.0)支持多种用例:

内核模块 内核的中间件 使用类、字符串或符号作为依赖标识符 常数值注入 类构造函数的注入 工厂注入 汽车工厂 提供程序的注入(异步工厂) 激活处理程序(用于注入代理) 多注射 标记绑定 自定义标记装饰器 指定绑定 上下文绑定 友好的异常(例如循环依赖)

你可以在InversifyJS上了解更多。

为了很好地测试应用程序，大多数时候最好使用反转控制工具在运行/测试时注入所需的对象。 所以最好不要在模块中直接使用require或import。而是调用DI容器来获取所需的对象。

如果你不想使用第三方库，你可以通过创建一个定制的DI容器来模仿IoC工具的行为。 在测试的时候，你可以模拟你的DI容器，并注入你的假模块用于测试。 下面是一个自定义DI容器的例子，这个版本的容器不支持接口。

myDependecy.js

const myDependecy = {};
export default myDependecy;

myDependecy.myTestFunction = () => {
  console.log("this is as test function.");
};

diContainer.js

import myDependecy from "./myDependecy.js";

const diContainer = {};
export default diContainer;

diContainer.myDependecy = myDependecy;

myModule.js

import diContainer from "./diContainer.js";

function myFunction() {
  diContainer.myDependecy.myTestFunction();
}

我知道这个帖子在这一点上是相当老的，但我想我会在这个问题上发表我的想法。TL;DR是由于JavaScript的无类型、动态特性，您实际上可以在不依赖依赖注入(DI)模式或使用DI框架的情况下做很多事情。然而，随着应用程序变得越来越大、越来越复杂，DI无疑可以帮助提高代码的可维护性。

c# DI

要理解JavaScript中为什么不需要依赖注入，看看强类型语言(如c#)是很有帮助的。(向那些不懂c#的人道歉，但它应该很容易理解。)假设我们有一个应用程序描述了一辆汽车和它的喇叭。你将定义两个类:

class Horn
{
    public void Honk()
    {
        Console.WriteLine("beep!");
    }
}

class Car
{
    private Horn horn;

    public Car()
    {
        this.horn = new Horn();
    }

    public void HonkHorn()
    {
        this.horn.Honk();
    }
}

class Program
{
    static void Main()
    {
        var car = new Car();
        car.HonkHorn();
    }
}

以这种方式编写代码几乎没有什么问题。

The Car class is tightly coupled to the particular implementation of the horn in the Horn class. If we want to change the type of horn used by the car, we have to modify the Car class even though its usage of the horn doesn't change. This also makes testing difficult because we can't test the Car class in isolation from its dependency, the Horn class. The Car class is responsible for the lifecycle of the Horn class. In a simple example like this it's not a big issue, but in real applications dependencies will have dependencies, which will have dependencies, etc. The Car class would need to be responsible for creating the entire tree of its dependencies. This is not only complicated and repetitive, but it violates the "single responsibility" of the class. It should focus on being a car, not creating instances. There is no way to reuse the same dependency instances. Again, this isn't important in this toy application, but consider a database connection. You would typically have a single instance that is shared across your application.

现在，让我们重构它以使用依赖注入模式。

interface IHorn
{
    void Honk();
}

class Horn : IHorn
{
    public void Honk()
    {
        Console.WriteLine("beep!");
    }
}

class Car
{
    private IHorn horn;

    public Car(IHorn horn)
    {
        this.horn = horn;
    }

    public void HonkHorn()
    {
        this.horn.Honk();
    }
}

class Program
{
    static void Main()
    {
        var horn = new Horn();
        var car = new Car(horn);
        car.HonkHorn();
    }
}

我们已经做了两件关键的事情。首先，我们介绍了一个由Horn类实现的接口。这让我们可以将Car类编码到接口，而不是特定的实现。现在代码可以接受任何实现IHorn的东西。其次，我们从Car中取出喇叭实例化，并将其传入。这解决了上述问题，并将其留给应用程序的主要功能来管理特定的实例及其生命周期。

这意味着我们可以在不接触car类的情况下为car引入一种新的喇叭类型:

class FrenchHorn : IHorn
{
    public void Honk()
    {
        Console.WriteLine("le beep!");
    }
}

主程序可以直接注入一个FrenchHorn类的实例。这也极大地简化了测试。您可以创建一个MockHorn类注入到Car构造函数中，以确保您只测试Car类。

上面的例子展示了手动依赖注入。典型的依赖注入是通过框架完成的(例如c#世界中的Unity或Ninject)。这些框架将通过遍历依赖关系图并根据需要创建实例来为您完成所有依赖关系连接。

标准的Node.js方式

现在让我们看看Node.js中的相同示例。我们可能会把代码分成3个模块:

// horn.js
module.exports = {
    honk: function () {
        console.log("beep!");
    }
};

// car.js
var horn = require("./horn");
module.exports = {
    honkHorn: function () {
        horn.honk();
    }
};

// index.js
var car = require("./car");
car.honkHorn();

因为JavaScript是无类型的，所以我们没有以前那样的紧密耦合。不需要接口(也不存在接口)，因为car模块只会尝试在horn模块导出的任何内容上调用honk方法。

此外，因为Node需要缓存所有内容，所以模块本质上是存储在容器中的单例。对horn模块执行require的任何其他模块都将获得完全相同的实例。这使得共享单例对象(如数据库连接)非常容易。

现在仍然存在一个问题，即car模块负责获取它自己的依赖喇叭。如果希望汽车使用不同的喇叭模块，则必须更改car模块中的require语句。这不是一件很常见的事情，但它确实会导致测试问题。

通常人们处理测试问题的方法是使用proxyquire。由于JavaScript的动态特性，proxyquire会拦截需要的调用，并返回您提供的存根/mock。

var proxyquire = require('proxyquire');
var hornStub = {
    honk: function () {
        console.log("test beep!");
    }
};

var car = proxyquire('./car', { './horn': hornStub });

// Now make test assertions on car...

这对于大多数应用程序来说已经足够了。如果它适用于你的应用，那就采用它。然而，根据我的经验，随着应用程序变得越来越大、越来越复杂，维护这样的代码变得越来越困难。

JavaScript中的DI

Node.js非常灵活。如果你对上面的方法不满意，你可以使用依赖注入模式来编写你的模块。在此模式中，每个模块导出一个工厂函数(或类构造函数)。

// horn.js
module.exports = function () {
    return {
        honk: function () {
            console.log("beep!");
        }
    };
};

// car.js
module.exports = function (horn) {
    return {
        honkHorn: function () {
            horn.honk();
        }
    };
};

// index.js
var horn = require("./horn")();
var car = require("./car")(horn);
car.honkHorn();

这与前面的c#方法非常相似，因为index.js模块负责实例生命周期和连接。单元测试非常简单，因为您只需将mock /存根传递给函数。同样，如果这对您的应用程序来说足够好，那么就使用它。

Bolus DI框架

与c#不同的是，没有现成的标准依赖注入框架来帮助你管理依赖项。npm注册表中有许多框架，但没有一个被广泛采用。这些选项中的许多已经在其他答案中被引用。

我对所有的选项都不是特别满意，所以我写了自己的bolus。Bolus的设计是为了与上面的DI风格编写的代码一起工作，并试图非常DRY和非常简单。使用上面完全相同的car.js和horn.js模块，你可以用bolus重写index.js模块:

// index.js
var Injector = require("bolus");
var injector = new Injector();
injector.registerPath("**/*.js");

var car = injector.resolve("car");
car.honkHorn();

基本思想是创建一个注入器。你在注入器中注册了所有的模块。然后你只需解决你所需要的。Bolus将遍历依赖关系图，并根据需要创建和注入依赖关系。在这样一个简单的例子中，您不会节省太多，但是在具有复杂依赖树的大型应用程序中，节省的时间是巨大的。

Bolus supports a bunch of nifty features like optional dependencies and test globals, but there are two key benefits I've seen relative to the standard Node.js approach. First, if you have a lot of similar applications, you can create a private npm module for your base that creates an injector and registers useful objects on it. Then your specific apps can add, override, and resolve as needed much like how AngularJS's injector works. Second, you can use bolus to manage various contexts of dependencies. For example, you could use middleware to create a child injector per request, register the user id, session id, logger, etc. on the injector along with any modules depending on those. Then resolve what you need to serve requests. This gives you instances of your modules per request and prevents having to pass the logger, etc. along to every module function call.

我认为其他的文章在使用DI的论证方面做得很好。对我来说，原因是

注入依赖项而不知道它们的路径。这意味着如果您更改磁盘上的模块位置或将其与另一个模块交换，则不需要触及依赖于该模块的每个文件。 它使模拟依赖关系以进行测试变得更加容易，而不用痛苦地重写全局require函数，而且不会出现任何问题。 它可以帮助您将应用程序组织为松散耦合的模块。

但是我很难找到一个我和我的团队可以轻松采用的依赖注入框架。所以我最近基于这些特性构建了一个名为deppie的框架

可以在几分钟内学会的最小API 不需要额外的代码/配置/注释 一对一直接映射需要的模块 可以部分地使用现有代码吗

我制作《电解质》就是为了这个目的。其他依赖注入解决方案对我来说太有侵入性了，而混淆全局require是我特别不满的地方。

电解质包含模块，特别是那些导出“设置”功能的模块，就像你在Connect/Express中间件中看到的那样。本质上，这些类型的模块只是它们所返回的对象的工厂。

例如，创建数据库连接的模块:

var mysql = require('mysql');

exports = module.exports = function(settings) {
  var connection = mysql.createConnection({
    host: settings.dbHost,
    port: settings.dbPort
  });

  connection.connect(function(err) {
    if (err) { throw err; }
  });

  return connection;
}

exports['@singleton'] = true;
exports['@require'] = [ 'settings' ];

您在底部看到的是注释，这是一个额外的元数据，电解质使用它来实例化和注入依赖关系，自动将应用程序的组件连接在一起。

创建一个数据库连接。

var db = electrolyte.create('database');

电解质传递遍历@require'd依赖项，并将实例作为参数注入导出函数。

关键是这是微创的。这个模块是完全可用的，独立于电解质本身。这意味着您的单元测试可以只测试被测试的模块，传入模拟对象，而不需要额外的依赖关系来重新连接内部。

当运行完整的应用程序时，电解质在模块间级别介入，将东西连接在一起，而不需要全局变量、单例或过多的管道。

Node.js和其他平台一样需要DI。如果您正在构建一些大的东西，DI将使您更容易模拟代码的依赖关系并彻底测试代码。

例如，数据库层模块不应该只在业务代码模块中使用，因为在单元测试这些业务代码模块时，dao将加载并连接到数据库。

一种解决方案是将依赖项作为模块参数传递:

module.exports = function (dep1, dep2) {
// private methods

   return {
    // public methods
       test: function(){...}
   }
}

通过这种方式，依赖关系可以轻松自然地模拟，你可以专注于测试你的代码，而不需要使用任何棘手的第三方库。

还有其他的解决方案(百老汇，建筑师等)可以帮助你解决这个问题。尽管他们可能做的比你想要的多，或者使用更多的杂物。