测试的 TDD 方法问题答案

【问题标题】：TDD approach issue with test测试的 TDD 方法问题
【发布时间】：2020-07-13 13:55:36
【问题描述】：

我是 TDD 实践的新手，我想知道我的方法是否适合特殊情况。

我想编写一个小软件，它在参数中获取一组数组字符串并拆分该组中的所有字符串。

例子：

{"C - 3 - 3", "M - 5 - 5"} 应该返回 { {"C", "3", "3"}, {"M", "5", "5"} }

通过解决问题，我开始使用带有 TDD 的 StringSplitter 和 StringSplitterTest，以便将一个字符串拆分为一个字符串数组。

之后，我编写了一个 StringGroupSplitter 和 StringGroupSplitterTest（总是使用 TDD 方法）做同样的事情，但是使用一个字符串数组（知道 StringGroupSplitter 具有 StringSplitter 依赖项）。

所以，我想起了单元测试的“FIRST”原则，尤其是独立性原则，即测试不应该依赖于另一个测试的结果。

在我的情况下，问题是由于StringGroupSplitter和StringSplitter的依赖，如果StringSplitterTest中只有ont测试失败，StringGroupSplitterTest中的测试也会失败。

所以我的问题如下：我的 TDD 方法是否正确？

提前致谢。

【问题讨论】：

【解决方案1】：

我记得单元测试的“FIRST”原则，尤其是独立性原则，即测试不应依赖于另一个测试的结果。

重要的想法是，无论运行顺序如何，测试都应该产生准确的测量结果。如果我们有一个“蓝色”测试和一个“橙色”测试，那么我们应该能够单独运行任何一个测试，或者以任一顺序运行两个测试，并获得关于我们的实现是否与我们的规范一致的准确信息。

在过去，耦合测试是一种常见的反模式。当所有测试都成功时，一切都很好。但是如果一个测试失败了，接下来会出现一连串不可信的结果，仅仅是因为后续测试的前提条件可能不满足。

您对字符串拆分器的描述并不表明您在这里有问题。如果StringGroupSplitter 依赖于StringSplitter 的一部分，并且您在该部分中引入了一个错误，那么多次测试失败是正常的。当我们担心反模式时，这不是我们的意思。

【讨论】：