1

Entity Framework(EF) のモックに関するこの投稿を読みました。

エンティティの型も抽象化すべきではありませんか? データ アクセス層 (DAL) とビジネス層 (BL) の間のデカップリングを維持するには?

上記の投稿で、彼は EF 具体的に生成されたエンティティ タイプを使用しました。

[TestMethod]
public void GetCustomer()
{
    ContextContainerMock container = new ContextContainerMock();
    IMyEntities en = container.Current;

**Customer c = new Customer { ID = 1, FirstName = "John", LastName = "Doe" };**
    en.Customers.AddObject(c);

    CustomerService service = new CustomerService(container);
    var a = service.GetCustomer(1);

    Assert.AreEqual(c.FirstName, a.FirstName);
    Assert.AreEqual(c.LastName, a.LastName);
}
4

2 に答える 2

2

個人的に、私はこれらを嘲笑しません。作成、テスト、クリーンアップを直接行います。これは、データベースを扱うときに、より現実的なシナリオの問題を把握するのに役立ちました。モッキングは、DB などのリソースにアクセスできない可能性がある統合をテストするのに最適です。これがあなたの場合であれば、選択の余地がないかもしれません。それが役立つことを願っています。

于 2012-10-28T13:42:52.020 に答える
0

短い答えはノーです。

エンティティは、正しく行われた場合、他のエンティティと値オブジェクト (string、int、または独自の値オブジェクトなど) を除いて、他のコードに依存しません。したがって、それらをあざける必要はありません。

また、エンティティはシステムのコアの一部です。それらはあなたのシステムのすべてです。通常、システムがどのように動作するかをテストするのではなく、これらのクラスで動作するときにシステムがどのように動作するかをテストする必要があります。

(補足として、エンティティは現実世界に存在するもののように見え、動作する必要があります。つまり、組織のビジネス側の非技術者との動作について推論できる必要があります。あなたの例 名前なしで Customer を作成できることがわかりました. ビジネスの観点からそれは問題ありませんか? そうでない場合は、コンストラクターに姓と名を引数としてとらせる必要があると思います.)

于 2012-10-29T20:01:06.483 に答える