依存性注入への段階的なアプローチ

私は、依存性注入を使用して、クラスをユニットテスト可能にすることに取り組んでいます。しかし、これらのクラスの一部には多くのクライアントがあり、依存関係を渡すためにそれらすべてをリファクタリングする準備がまだできていません。だから私は徐々にそれをやろうとしている。現時点ではデフォルトの依存関係を維持しますが、テストのためにそれらをオーバーライドできます。

私が考えているアプローチの1つは、すべての「新しい」呼び出しを独自のメソッドに移動することです。たとえば、

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

次に、単体テストでこのクラスをサブクラス化し、作成関数をオーバーライドして、代わりに偽のオブジェクトを作成します。

これは良いアプローチですか？欠点はありますか？

より一般的には、テストのために依存関係を置き換えることができる限り、ハードコードされた依存関係を使用しても大丈夫ですか？私は、コンストラクタで明示的にそれらを要求することが好ましいアプローチであることを知っており、最終的にそこに到達したいと思います。しかし、私はこれが良い最初のステップかどうか疑問に思っています。

私に発生した欠点の1つは、テストする必要がある実際のサブクラスがある場合、親クラス用に作成したテストサブクラスを再利用できないことです。実際のサブクラスごとにテストサブクラスを作成する必要があり、同じ作成関数をオーバーライドする必要があります。

これは、開始するのに適した方法です。ことを注意最も重要なのは、ユニットテストを使用して、既存のコードをカバーすることです。テストが完了したら、自由にリファクタリングして設計をさらに改善できます。

したがって、最初のポイントは、デザインをエレガントで光沢のあるものにすることではなく、コードユニットを最小限のリスクで変更してテスト可能にすることです。単体テストを使用しない場合、コードの破損を防ぐために、より慎重で慎重でなければなりません。これらの最初の変更は、場合によってはコードをより不格好にしたりいように見せたりすることもありますが、最初の単体テストを作成できるようになれば、最終的には思い描いている理想的な設計に向けてリファクタリングできるようになります。

このテーマに関する基本的な作業は、レガシーコードを効果的に使用することです。それは、あなたが上で示したトリックと、多くの、さらに多くの、いくつかの言語を使用して説明しています。

Guiceの人々は

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

@Injectを定義に追加するだけでなく、すべてのプロパティに対して。これにより、それらを通常のBeanとして扱うことができます。これはnew、テスト中（およびプロパティを手動で設定する場合）および本番環境で@Inject する場合に使用できます。

この種の問題に直面した場合、クラスからテストへの各依存関係を識別し、それらを渡すことができる保護されたコンストラクターを作成します。これは、それぞれのセッターを作成するのと実質的に同じですが、コンストラクターで依存関係を宣言して、将来それらをインスタンス化することを忘れないようにします。

したがって、新しいユニットテスト可能クラスには2つのコンストラクタがあります。

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

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

注入された依存関係を使用できるようになるまで、「getter create」イディオムを検討することをお勧めします。

例えば、

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
    }
  }
}

これにより、ゲッターを介してmyObjectを参照できるように内部的にリファクタリングできます。電話する必要はありませんnew。将来的に、すべてのクライアントが依存性注入を許可するように構成された場合、必要なことは作成コードを1か所（ゲッター）で削除することだけです。セッターを使用すると、必要に応じてモックオブジェクトを注入できます。

上記のコードは単なる例であり、内部状態を直接公開します。このアプローチがコードベースに適しているかどうかを慎重に検討する必要があります。

また、主要なリファクタリングを成功させるための便利なヒントが豊富に含まれている「レガシーコードを効果的に使用する」を読むことをお勧めします。