0

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

我的问题是

  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>

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

4

1 回答 1

3

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

一个应该对您有很大帮助的提示：

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

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

于 2013-10-23T20:05:11.253 回答