带有 Web 配置的 TDD

Question

所有伟大的故事总是以这 4 个神奇的词开始......我继承了一个系统......不等等！这是不对的！

不管怎样，我的幽默尝试现在已经过去了，我没有得到更多的支持，我必须支持现有的服务。

使用此服务时会遇到很多问题，例如创建一个人的记录，您需要调用服务的 4 个不同部分。

因此，与我的经理一起，我们决定需要在顶部添加另一层来为常见请求添加外观，以简化创建新站点时的数量和执行这些操作的正确顺序。

如果有人想避免上述华夫饼，我的问题就从这里开始

所以我想在我正在做的工作中使用TDD，但是我继承的服务（将成为我们的数据层）已经强耦合了数据库连接字符串位于 Web.Config 中的特定 connetionstring 节点中。

我遇到的问题是，将服务与配置文件分离将花费我几周的时间，而我没有时间。

因此，我必须将带有预期节点的 App.Config 文件添加到我的测试项目中。

这样做可以吗，还是我应该开始投入一些时间将数据库配置与数据层解耦？

Answer 1

我同意您可能应该考虑使用依赖注入来通过代码将应用程序与配置解耦，但是，我也明白这样做并不是一件容易的事。

因此，直接回答您的问题，不，添加配置文件来支持您的测试没有任何问题。这对于对遗留系统进行单元测试实际上很常见（遗留系统是未经测试的系统）。当没有其他选择时，我还诉诸利用反射将假配置值“注入”到 ConfigurationManager 中，以测试正在读取配置值的代码，但这可能是最后的手段。

Answer 2

尝试使用依赖注入来模拟您的数据层。

在 TDD 中，您（不一定）不测试数据层和数据库，而是测试业务逻辑。

一些链接：

• 使用 C# 和 rhinomocks 的 tdd 最佳实践
• TDD - Rhino Mocks - 第 1 部分 - 简介

Answer 3

您可以使用依赖注入从 web.config（或 app.config）中“解开”您的代码：

http://weblogs.asp.net/psteele/archive/2009/11/23/use-dependency-injection-to -简化应用程序设置.aspx

Answer 4

正如您提到的，依赖注入是可行的方法。您还希望确保配置对象的使用者不依赖于您的特定配置实现，例如 ConfigurationManager、ConfigurationSections 等。要查看使用自定义配置的完整示例，您可以查看我的博客文章 配置忽略 但基本上它包括。

无论是使用 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 的工厂设施。

希望有帮助。