以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，但我也认为这是不好的做法。 此类需要密封吗？

尝试着重于使方法有效的设计，而不必假设可能的特定实现。 如果发现自己传递了太多东西，则可能需要一个新的班级。 如果发现自己一次做太多事情，则可能需要更多方法。