後で単体テストできるようにリポジトリを Manager クラスに渡す必要がありますか、それとも単にリポジトリをテストするだけですか?
各クラスを個別にテストする必要があります。Manager クラスには実際のビジネス ロジックが含まれているため、おそらくいくつかのシナリオをテストする必要があります。
CatRepository.Add
名前が無効な場合は呼び出されず、有効な場合は正しい名前で呼び出されるようにする必要があります。これを実現するには、Manager
クラスが interface で動作することを確認しますICatRepository
。単体テストでは、モックと呼ばれる手法を使用して、 ICatRepositoryの偽の実装を Manager クラスに渡します。モックには、どのメソッドが呼び出されたかを確認し、それらのメソッドへの引数を検証できる特別な機能があります。
これは、マネージャが CatRepository 自体を構築してはならないことを意味します。
// Not a good solution
public class Manager
{
public Manager()
{
this.catRepository = new CatRepository();
}
}
CatRepository
この方法では、をモックしたバージョンに置き換える方法がありません。代わりに、依存性注入と呼ばれる方法を使用する必要があります。
// Seperate construction from business logic
public class Manager
{
public Manager(ICatRepository catRepository)
{
this.catRepository = catRepository;
}
}
CatRepository
実際のロジックは含まれていません。統合テスト (実際のデータベースまたはその他の外部オブジェクトを使用する低速の実行テスト) を使用して、リポジトリが正しく機能することを確認できます。
私は約 1 年前にこのテーマについてブログを書きました。このブログでは、統合テストと単体テストの違いと、モッキングが優れた単体テストの作成にどのように役立つかを説明しています:単体テスト、地獄か天国か?
単体テストできるように、コンテキストをリポジトリに渡したいです。したがって、インターフェイス IMyContext を作成しますが、EF コンテキストを取得してそれを実装する方法がわかりません。追加する場所は自動生成されたコードであり、それが消去されるのではないかと心配しています。カスタム コンテキストをリポジトリに渡せるようにする他の方法はありますか?
コンテキストは として生成されますpartial class
。部分的とは、クラスを複数の .cs ファイルに分散できることを意味します。コンパイラはこれらのファイルをマージし、1 つのクラスを出力します。このようにして、EF によって自動生成される 1 つの .cs ファイルと、インターフェイスを実装する別のファイルを持つことができます。このようなもの:
mycontext.cs
public partial class MyContext : ObjectContext
{ }
mycontextinterface.cs
public interface IMyContext {}
public partial class MyContext : IMyContext
{ }