Question

我已经开始考虑在项目中围绕某些业务逻辑添加一些单元测试。

我想测试的第一个方法是我的服务层中的一个方法，它返回给定节点的子节点列表。

方法如下：

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;
}

我想象这样测试的方法是提供一个假的Tree结构，然后测试提供一个节点返回正确的子节点。

ssdsContext是ObjectContext。

我已经看到可以为ObjectContext How to mock ObjectContext or ObjectQuery<T> in Entity Framework?提取和界面，但我也读过，嘲笑DBContext是浪费时间Unit Testing DbContext

我还读到，由于实体框架是存储库模式和工作单元的实现，例如：Generic Repository With EF 4.1 what is the point。

这让我有点困惑......是否是测试这样一个方法创建存储库层的唯一真正方法？是否值得单元测试这种方法？

Answer 1

将ObjectContext类包装在一个包装类中 - 让我们将其称为ContextWrapper以获得乐趣 - 只显示您需要的内容。然后，您可以使用您的方法将此接口（IContextWrapper）注入到您的类中。包装器可以被模拟，没有连接到外部世界的钩子。正如您所说，树结构很容易创建，并从模拟对象中获取。因此，使您的测试TRUE单元测试而不是一种集成测试。

服务层中的单元测试方法

1 个答案: