1

プロジェクトのビジネス ロジックに単体テストを追加することを検討し始めました。

最初にテストしたいメソッドは、特定のノードの子ノードのリストを返すサービス層のメソッドです。

メソッドは次のようになります。

public List<Guid> GetSubGroupNodes(string rootNode)
{
    List<Tree> tree = ssdsContext.Trees.ToList();
    Tree root = ssdsContext.Trees.Where(x => x.UserId == new Guid(rootNode)).FirstOrDefault();
    return GetChildNodeIds(root, tree);
} 

private List<Tree> GetChildNodes(Tree rootNode, List<Tree> tree)
{
    kids.Add(rootNode);
    foreach (Tree t in FindChilden(rootNode, tree))
    {
        GetChildNodes(t, tree);
    }
     return kids;
}

このようなテストをイメージする方法は、偽のツリー構造を提供し、ノードを提供すると正しいサブノードが返されることをテストすることです。

ssdsContextですObjectContext。

ObjectContext Entity Framework で ObjectContext または ObjectQuery<T> をモックする方法を抽出してインターフェイスすることが可能であることを確認しました。しかし、 a をモックすることはDbContextDBContextの単体テストの時間の無駄であることも読みました。

また、Entity Framework はリポジトリ パターンと作業単位の実装であり、ここでパターン化されていることも読みました: Generic Repository With EF 4.1 what is the point .

これはすべて私を少し混乱させました...リポジトリレイヤーを作成するためにこのような方法をテストする唯一の本当の方法ですか? このメソッドを単体テストする価値はありますか?

4

1 に答える 1

2

ObjectContext クラスを wrapperclass でラップします (楽しみのために ContextWrapper と呼びましょう)。これにより、必要なものだけが公開されます。次に、この (IContextWrapper) のインターフェイスを、メソッドを使用してクラスに挿入できます。ラッパーは、外界に接続されたフックなしでモックできます。あなたが言うように、ツリー構造は簡単に作成でき、モック オブジェクトから取得できます。したがって、一種の統合テストではなく、テストを TRUE 単体テストにします。

于 2012-10-03T10:55:40.583 に答える