所有伟大的故事都是从这四个神奇的词开始的……我继承了一个系统……等不及了！这是不对的！
无论如何，我的幽默尝试现在已经过去了，我并没有得到更多我必须支持现有服务的东西。
使用这个服务有很多问题，比如创建一个人的记录，你需要调用4个不同的服务部分。
因此，与我的经理一起，我们决定需要在顶部添加另一层，以便为常见请求添加外观，以简化创建新站点时的数量和执行它们的正确顺序。
如果有人想避免上述华夫饼，我的问题就从这里开始
所以我想在我正在做的工作中使用 TDD，但是我继承的服务（将成为我们的数据层）已经与位于 Web.Config 中特定连接字符串节点中的数据库连接字符串强耦合.
我遇到的问题是，将服务与 Config 文件分离将花费我数周的时间，而我没有时间。
所以我不得不将带有预期节点的 App.Config 文件添加到我的测试项目中。
这样做可以吗，还是我应该开始投入一些时间来将数据库配置与数据层分离？
【问题讨论】：
标签： c# configuration tdd decoupling
我同意您可能应该考虑使用依赖注入作为您通过代码来将您的应用与配置分离的方式，但是，我也明白这样做不会是一件容易的事。
所以，直接回答您的问题，不，添加配置文件来支持您的测试没有任何问题。这对于单元测试遗留系统（遗留系统是未经测试的系统）实际上很常见。我也曾在别无选择的情况下使用反射将虚假配置值“注入”到 ConfigurationManager 中，以测试正在读取配置值的代码，但这可能是最后的手段。
【讨论】：
尝试使用依赖注入来模拟您的 DataLayer。
在 TDD 中，您不是（必然）测试数据层和数据库，而是测试业务逻辑。
一些链接：
【讨论】：
您可以使用依赖注入从 web.config（或 app.config 中）“解绑”您的代码：
【讨论】：
正如你提到的依赖注入是要走的路。您还想确保您的配置对象的使用者不依赖于您的特定配置实现，例如 ConfigurationManager、ConfigurationSections 等。要查看使用自定义配置的完整示例，您可以查看我在 @987654321 上的博客文章@ 但基本上它包括。
您的配置实现（无论是使用 ConfigurationSection 还是 XmlReader）都应该基于一个接口，这样您就可以轻松地模拟您的属性并在以后轻松地更改您的实现。
public BasicConfigurationSection : ConfigurationSection, IBasicConfiguration
{
...
}
为了解决如何重试配置，我们使用配置提供程序，特定配置的配置提供程序知道如何检索它的配置
public interface IConfigurationProvider<TConfiguration>
{
TConfiguration GetConfiguration();
}
public class BasicConfigurationProvider : IConfigurationProvider<IBasicConfiguration>
{
public IBasicConfiguration GetConfiguration()
{
return (BasicConfigurationSection)ConfigurationManager.GetSection("Our/Xml/Structure/BasicConfiguration");
}
}
如果您使用的是 Windsor，则可以将其连接到 Windsor 的工厂设施。
希望对您有所帮助。
【讨论】：