渐进式依赖注入方法

我正在使用依赖注入使我的课程可单元测试。但是其中一些类有很多客户端，而且我还没有准备好重构所有这些类以开始传递依赖项。所以我正在努力逐步做到；暂时保留默认依赖关系，但允许对其进行覆盖以进行测试。

我正在考虑的一种方法是将所有“新”调用移入它们自己的方法，例如：

public MyObject createMyObject(args) {
  return new MyObject(args);
}

然后，在我的单元测试中，我可以继承该类的子类，并覆盖create函数，以便由它们创建伪造的对象。

这是一个好方法吗？有什么缺点吗？

更一般而言，只要您可以替换它们以进行测试，就可以使用硬编码的依赖项吗？我知道首选方法是在构造函数中明确要求它们，而我希望最终到达那里。但是我想知道这是否是一个好的第一步。

我刚想到的一个缺点是：如果您有需要测试的真实子类，则无法重用为父类编写的测试子类。您必须为每个真实的子类创建一个测试子类，并且它必须覆盖相同的create函数。

这是入门的好方法。请注意，最重要的是使用单元测试覆盖现有代码。一旦进行了测试，就可以更自由地进行重构以进一步改进设计。

因此，最初的目的不是使设计优雅而有光泽-只是使代码单元可以以最小的风险更改进行测试。如果没有单元测试，则必须格外保守和谨慎，以免破坏代码。在某些情况下，这些初始更改甚至可能使代码看起来更笨拙或丑陋-但是，如果它们使您能够编写第一个单元测试，则最终您将能够重构为您所想到的理想设计。

关于此主题的基本工作是有效地使用旧版代码。它描述了您使用多种语言在上面展示的技巧，以及许多其他更多技巧。

Guice民间推荐使用

@Inject
public void setX(.... X x) {
   this.x = x;
}

所有属性，而不仅仅是在其定义中添加@Inject。这将使您可以将它们视为普通bean，可以new在测试（和手动设置属性）和在生产中使用@Inject时使用。

当我遇到此类问题时，我将识别要测试的类的每个依赖项，并创建一个受保护的构造函数，该构造函数将允许我将它们传递给我。这实际上与为每个类创建一个setter相同，但是我更喜欢在我的构造函数中声明依赖关系，这样我就不会忘记在将来实例化它们。

因此，我的新单元可测试类将具有2个构造函数：

public MyClass() { 
  this(new Client1(), new Client2()); 
}

public MyClass(Client1 client1, Client2 client2) { 
  this.client1 = client1; 
  this.client2 = client2; 
}

在可以使用注入的依赖项之前，您可能要考虑“ getter创建”惯用语。

例如，

public class Example {
  private MyObject myObject=null;

  public MyObject getMyObject() {
    if (myObject==null) {
      myObject=new MyObject();
    } 
    return myObject;
  }

  public void setMyObject(MyObject myObject) {
    this.myObject=myObject;
  }

  private void myMethod() {
    if (getMyObject().doSomething()) {
      // Instance automatically created
    }
  }
}

这将允许您在内部进行重构，以便可以通过getter引用myObject。您无需致电new。将来，当所有客户端都配置为允许依赖项注入时，您要做的就是将创建代码删除到一个位置-吸气剂。设置器将允许您根据需要注入模拟对象。

上面的代码仅是一个示例，它确实直接公开内部状态。您应该仔细考虑这种方法是否适合您的代码库。

我还建议您阅读“ 有效地使用旧版代码 ”，其中包含许多有用的技巧，可以使重大重构成功。