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

当サイトではアフィリエイト広告を利用しています。

NDDD

前回はユーザーインタフェース層のフォルダー構成に関するお話をしました。今回は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というツールがあります。これは純正のマイクロソフトのテストコードを,書きやすくしてくれるツールなので,使用をお勧めします。