1

EFモデルをテストします。これを行うために、IDbContextクラスを作成しました。しかし、 db.Partner.AddObject（obj）;の書き方がわからないため、SaveメソッドとDeleteメソッドを書き直す方法がわかりません 。これらのメソッドを書き直す方法は？

public interface IDbContext
    {
        int SaveChanges();
        DbSet<Partner> Partner { get; set; }    
    }    
public class PartnerRepository : IPartnerRepository
{
    readonly IDbContext _context;
    public PartnerRepository()
    {
        _context = (IDbContext)new VostokPortalEntities();
    }
    public PartnerRepository(IDbContext context)
    {
        _context = context;
    }

    public void Save(Partner obj)
    {
        using (var db = new VostokPortalEntities())
        {
            if (obj.PartnerID == 0)
            {
                db.Partner.AddObject(obj);
            }
            else
            {
                db.Partner.Attach(obj);
                db.ObjectStateManager.ChangeObjectState(obj, System.Data.EntityState.Modified);
            }
            db.SaveChanges();
        }
    }
    public void Delete(Partner obj)
    {

        using (var db = new VostokPortalEntities())
        {

            db.Partner.Attach(obj);
            db.ObjectStateManager.ChangeObjectState(obj, System.Data.EntityState.Deleted);
            db.SaveChanges();
        }
    }
    public List<Partner> GetAll()
    {
        using (var db = new VostokPortalEntities())
        {
            return db.Partner.OrderByDescending(i => i.PartnerID).ToList();
        }
    }
}

これはEFモデルをテストするための適切な方法ですか？

4

1 に答える 1

4

リポジトリの単体テストには多くの時間がかかり、多くのメリットはありません。なんで？リポジトリには複雑なビジネスロジックがないためです。通常、基盤となるデータアクセスAPI（ORM）への非常に単純な呼び出しがあります。フルスタックの受け入れテストの作成に時間を費やす方が適切だと思います。これにより、リポジトリがその役割を果たしているかどうかもわかります。

ところで、興味深いルールがあります。所有していないものをモックしないでください。

私たちが所有していないタイプのモックバージョンとの相互作用をテストすることにより、私たちは実際にテストを使用して正しい動作をチェックしたり、共同作業者の設計を追い出したりしていません。私たちのテストが行​​っているのは、他のタイプがどのように機能するかについての推測を繰り返すことだけです。もちろん、テストを行わないよりはましですが、必ずしもそうとは限りません。

于 2012-07-23T08:25:43.723 に答える