中等复杂度方法的 TDD答案

【问题标题】：TDD for a medium complexity method中等复杂度方法的 TDD
【发布时间】：2009-03-09 11:54:49
【问题描述】：

我已经有一段时间没有接触 TDD，而且很生疏。我会很感激一些关于如何对下面描述的方法进行 TDD 的建议。

该方法必须在用户提供的应用程序目录中找到一个 web.config 文件。然后它必须从该配置文件中提取并返回一个连接字符串。

如果由于某种原因找不到连接字符串，则返回 null，无论是路径错误、没有 web.config 还是 web.config 中没有连接字符串。

我最初的想法是使用 setup 编写一个测试，该测试创建一个目录并编写一个带有连接字符串的 web.config 文件。然后测试将使用创建的路径调用我的方法并期望返回一个非空值，并且我的初始测试运行将失败，因为我的方法存根始终返回空值。

然后，实现该方法，并运行测试并期望通过。然后，作为预测试（我忘记了术语），删除创建的目录，并调用期望为空值的方法。

【问题讨论】：

标签： unit-testing tdd

【解决方案1】：

首先，我不会让方法既找到文件又提取连接字符串。如果您的框架还没有确定文件是否存在于给定目录中的方法，请编写一个方法来执行此操作，一旦您有了文件，请编写一个方法从打开的流中提取连接字符串。那么，为了测试，您可以提供内存流，而不必实际创建目录和文件。

其次，如果您不将失败的编译作为您的第一个失败测试，那么请编写您对抛出 NotImplementedException 的方法的第一次尝试。这是一小步，但是当您编写第一个测试时，至少它会失败。当然，对空流的第一个测试会期望它返回 null，而您编写的第一个代码将是 return null，但这没关系。你的下一个测试将迫使你改变它。从那里继续，直到你完成了你的方法。

【讨论】：

第 1 段：这是一个非常简单的案例，我更愿意将整个连接字符串任务封装在一个方法中，即使它绕过了单一职责准则。第 2 段：好点，我已经走了那条路。
@profk：如果你混合职责，你会发现 TDD 更难。在这种情况下，TDD 正在发挥作用 - 引导您采用不同的（也许主观上更好的）设计。

【解决方案2】：

您似乎有多个带有多个不同设置装置的测试用例。

FoundDirectory 测试用例。设置创建预期的有效文件。

这可以有几个子类。
1. 找不到连接字符串 TestCase。设置会创建预期但无效的文件。
2. TestCase 路径错误。设置会创建预期但无效的文件。
3. 没有 web.config 测试用例。设置会创建预期但无效的文件。
4. web.config TestCase 中没有连接字符串。设置会创建预期但无效的文件。
DintFindDirectory 测试用例。设置确保目录不存在。
DintFindFile 测试用例。设置创建目录但没有文件。

【讨论】：

我喜欢你的方法，但你的点 1.1 似乎有点重复点 1.4。您的意思是设置一个没有连接字符串元素的文件，而 1.4 有一个空的连接字符串元素？
我从问题描述中猜测测试用例。我不知道测试用例之间的真正区别——我只是从问题中的文字猜测。

【解决方案3】：

使持有你的方法（或方法本身）的对象依赖于某种IConfigLoader，你可以模拟：

public interface IConfigLoader
{
    XmlReader LoadAppConfigFrom(string path);
}

从你的方法中使用它来获取你想要解析的 XML 文件。

【讨论】：

【解决方案4】：

我建议您问题中的故事混合了几个问题：

查找并打开文件，
将数据加载到“配置”中（无论如何表示）
试图从“配置”中获取特定参数

第 3 点现在是关于配置行为方式的问题，并且可以以 TDD 方式开发。

第 2 点现在是关于如何构造配置（例如通过 ConfigurationLoader），并且可以以 TDD 方式开发（例如针对 StringReader）。

第 1 点现在是您是否可以打开指定文件路径的阅读器的问题。完成第2点后很容易添加。

【讨论】：