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