unit-testing
依存性注入

備考

if (DateTime.Now.Date > processDate)
{
    // Do some processing
}

コンストラクタインジェクション

コンストラクタインジェクションは、クラス全体が依存する依存関係を注入する最も安全な方法です。このような依存関係は、クラスのインスタンスを提供せずに作成できないため、 不変条件と呼ばれることがあります。構築時に依存性を注入することを要求することにより、オブジェクトが不整合な状態で作成されないことが保証される。

エラー状態でログファイルに書き込む必要のあるクラスを考えてみましょう。これはILoggerに依存してILogger 、必要に応じて注入して使用することができます。

public class RecordProcessor
{
    readonly private ILogger _logger;

    public RecordProcessor(ILogger logger)
    {
        _logger = logger;
    }

    public void DoSomeProcessing() {
        // ...
        _logger.Log("Complete");
    }
}

テストを書くときに、コンストラクタが実際にテストされるケースよりも多くの依存関係を必要とすることに気づくことがあります。そのようなテストが多いほど、クラスがSingle Responsibility Principle （SRP）を破る可能性が高くなります。そのため、潜在的な警告信号をマスクすることができるため、テストクラスの初期化フェーズで、注入された依存関係のすべてのモックに対してデフォルト動作を定義することは、あまり良い習慣ではありません。

unittestは次のようになります。

[Test]
public void RecordProcessor_DependencyInjectionExample()
{
    ILogger logger = new FakeLoggerImpl(); //or create a mock by a mocking Framework
    
    var sut = new RecordProcessor(logger); //initialize with fake impl in testcode

    Assert.IsTrue(logger.HasCalledExpectedMethod());
}

プロパティインジェクション

プロパティインジェクションにより、クラスの依存関係を作成後に更新することができます。これは、オブジェクトの作成を簡素化したいが、テストダブルでテストによって依存関係を上書きできるようにする場合に便利です。

エラー状態でログファイルに書き込む必要のあるクラスを考えてみましょう。クラスはデフォルトのLoggerどのように構築するのかを知っていますが、プロパティの注入によって上書きすることができます。しかし、この方法でプロパティインジェクションを使用すると、このクラスではこの例のConcreteLoggerであるILogger正確な実装と緊密に結合していることにILoggerがあります。可能な回避策は、必要なILogger実装を返すファクトリです。

public class RecordProcessor
{
    public RecordProcessor()
    {
        Logger = new ConcreteLogger();
    }

    public ILogger Logger { get; set; }

    public void DoSomeProcessing()
    {
        // ...
        _logger.Log("Complete");
    }
}

ほとんどの場合、コンストラクターインジェクションは、オブジェクトの作成直後にオブジェクトの状態をよりよく保証するため、プロパティインジェクションよりも優れています。

メソッド注入

メソッドインジェクションは、依存関係を処理に注入するきめ細かな方法です。現在の日付に基づいて何らかの処理を行うメソッドを考えてみましょう。現在の日付はテストから変更するのが難しいので、テストするメソッドに日付を渡す方がはるかに簡単です。

public void ProcessRecords(DateTime currentDate)
{
    foreach(var record in _records) 
    {
        if (currentDate.Date > record.ProcessDate)
        {
            // Do some processing
        }
    }
}

コンテナ/ DIフレームワーク

コードから依存関係を抽出して注入できるようにすると、コードを簡単にテストできるようになりますが、それは問題をさらに階層の上に押し上げ、結果として構築が困難なオブジェクトにもなります。様々な依存性注入フレームワーク/コントロールコンテナの反転がこの問題を克服するために書かれています。これにより、型マッピングを登録できます。これらの登録は、コンテナにオブジェクトの作成を依頼されたときに依存関係を解決するために使用されます。

次のクラスを考えてみましょう：

public interface ILogger {
    void Log(string message);
}

public class ConcreteLogger : ILogger
{
    public ConcreteLogger()
    {
        // ...
    }
    public void Log(string message)
    {
        // ...
    }
}
public class SimpleClass
{
    public SimpleClass()
    {
        // ...
    }
}

public class SomeProcessor
{
    public SomeProcessor(ILogger logger, SimpleClass simpleClass)
    {
        // ...
    }
}

SomeProcessorを構築するには、 ILoggerとSimpleClassインスタンスが必要です。 Unityのようなコンテナは、このプロセスを自動化するのに役立ちます。

最初にコンテナを構築してからマッピングを登録する必要があります。これは通常、アプリケーション内で1回だけ実行されます。これが発生するシステムの領域は、通常、 Composition Root

// Register the container
var container = new UnityContainer();

// Register a type mapping.  This allows a `SimpleClass` instance
// to be constructed whenever it is required.
container.RegisterType<SimpleClass, SimpleClass>();

// Register an instance.  This will use this instance of `ConcreteLogger` 
// Whenever an `ILogger` is required.
container.RegisterInstance<ILogger>(new ConcreteLogger());

コンテナが設定された後、オブジェクトを作成して、必要に応じて自動的に依存関係を解決することができます。

var processor = container.Resolve<SomeProcessor>();