ドメイン駆動開発_フォルダー構成編_#08_Testsのフォルダー構成

前回はユーザーインタフェース層のフォルダー構成に関するお話をしました。今回はTestsプロジェクトのフォルダー構成のお話をします。

フォルダー構成

テストプロジェクトでは，当然，本番コードに対してテストコードを書いていくので，どの本番コードに対してテストを書いているかがわかるようなフォルダー構成がいいでしょう。

例えばDomain層のValueObjectsフォルダーのMeasureValueというクラスに対してのテストであれば，Testsプロジェクトの直下にDomainフォルダーを作成し，その下に，ValueObjectsフォルダーを作成し，その直下に「MeasureValueTest」というテストクラスを作成して，テストコードを書きます。本番コードのプロジェクト名のフォルダーの下に，同様にフォルダーを作成し，テスト対象のクラスの語尾に「Test」と命名するようにすると，どのクラスに対するテストかがわかりやすくなります。

ViewModelへのテスト

テストコードはすべてのクラスに対して記述するという考え方ではなく，可能な限り，「テストを通過させる」という考え方でいいと思います。基本的には，ViewModelクラスが，DomainやInfrastructureの処理を呼び出すので，各ViewModelクラスへのテストコードを書けば，ViewModel，Domain層のカバレッジは90%程度カバーできると思います。カバレッジとは，テストコードでカバーできている比率の事です。100%はなかなか難しいので，90%程度カバーできていればOKです。

Infrastructureのテスト

Infrastructureは外部接触する部分なので，基本的にテストコードは不要です。その代わりにMoqというツールを使ってテストを行います。

画面のテスト

画面のテストもテストコードではできないので，ViewModelに対するテストコードを行います。実際に表示されるかどうかは，テストコードではなく，実際に動作させて確認するという，従来のテスト方法でテストを行います。

Chaining Assertion

NugetにChaining Assertionというツールがあります。これは純正のマイクロソフトのテストコードを，書きやすくしてくれるツールなので，使用をお勧めします。