2

所有伟大的故事都以这四个神奇的词开头……我继承了一个系统……等不及了！这是不对的！

无论如何，我的幽默尝试现在已经过去了，我没有得到更多我必须支持现有服务的东西。

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

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

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

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

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

所以我不得不将带有预期节点的 App.Config 文件添加到我的测试项目中。

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

4

4 回答 4

1

尝试使用依赖注入来模拟您的 DataLayer。

在 TDD 中，您不是（必然）测试您的数据层和数据库，而是测试 BusinessLogic。

一些链接：

于 2010-06-18T14:11:34.510 回答
1

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

http://weblogs.asp.net/psteele/archive/2009/11/23/use-dependency-injection-to-simplify-application-settings.aspx

于 2010-06-18T14:16:51.790 回答
1

我同意您可能应该考虑使用依赖注入作为您通过代码将您的应用程序与配置分离的方式，但是，我也明白这样做不会是一件容易的事。

所以，直接回答你的问题，不，添加配置文件来支持你的测试没有错。这对于单元测试遗留系统（遗留系统是未经测试的系统）实际上很常见。我也曾在别无选择的情况下，利用反射将虚假配置值“注入”到 ConfigurationManager 中，以测试正在读取配置值的代码，但这可能是最后的手段。

于 2010-06-19T02:11:56.710 回答
1

正如你提到的依赖注入是要走的路。您还想确保您的配置对象的使用者不依赖于您的特定配置实现，例如 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 的工厂。

希望有帮助。

于 2010-06-28T14:05:59.933 回答