使用 XML 作为数据源的单元测试存储库

Question

我是一个单元测试新手，正在努力寻找一种测试我的存储库的好方法。我创建了一个 CustomConfigurationManager 来加载我的 Custom.Config 值。但无法弄清楚如何测试它们。

我的问题是

1. 如何测试GetUserById()里面的代码
2. 如何测试我的CustomConfigurationManager()

这是我正在尝试测试的存储库：

public class UserRepository : IUserRepository
{
    public User GetUserById(string id)
    {
        return CustomConfigurationManager.CustomConfig.Users.FirstOrDefault(u => u.UserId == id);
    }
}


public class CustomConfigurationManager
{
    public static Configs CustomConfig
    {
        get
        {
            return CustomConfigLoader.LoadConfig<Configs>();
        }
    }
}

internal sealed class ConfigLoader
{
    public static T LoadConfig<T>() where T : class
    {
        ...

        return LoadFromXML<T>();
    }
}

还有 XML

 <users>
    <user id="Foo" name="Bar" ... />
    ...
</users>

我粘贴的代码是修改过的，不是真正的代码。这只是一个例子。

Answer 1

我相信很多人会指出，从某种意义上说，如果你正在读取一个文件，它就不是一个单元测试。真的，你应该以更宽松的方式测试类似的东西，或者想办法伪造它。

一个对你有很大帮助的提示：

public class UserRepository : IUserRepository
{
    public Configs CustomConfig {get;set;}
    public User GetUserById(string id)
    {
        return CustomConfig.Users.FirstOrDefault(u => u.UserId == id);
    }
}

这个想法是通过注入它（可能只在构造函数中），您可以在不读取文件的情况下对其进行测试。这称为 DI（依赖注入），通常最好使用接口来完成。

您的 CustomConfigurationManager 很难测试，因为它在属性中调用了另一个静态方法；你可能只是不使用它。这是一种额外的复杂性，它隐藏了细节但也隐藏了依赖关系，这是你永远不想做的。

如果没有 InternalsVisibleTo，您将无法真正测试 ConfigLoader，但我也认为这是一种不好的做法。这个类需要密封吗？

尝试将您的设计重点放在使方法有效，而不是尽可能假设特定的实现。如果你发现自己传递了太多东西，你可能需要一个新的类。如果你发现自己一次做的事情太多，你可能需要更多的方法。