tdd - TDD 会留下哪些故障模式？

Question

请注意，我还没有在 TDD 上“看到曙光”，也没有真正理解为什么它的主要支持者宣扬了它的所有好处。我并没有否认它 - 我只是有我的保留意见，这可能是出于无知。所以无论如何都要笑下面的问题，只要你能纠正我:-)

使用 TDD 是否会让您对实现的意外副作用持开放态度？ “满足测试所需的最少代码量”的概念建议以最狭隘的方式思考特定问题，而不必考虑更大的图景。

我正在考虑持有或依赖状态的对象(例如内部字段值)。如果您有单独实例化对象的测试，初始化该对象，然后调用被测方法，您如何发现不同的方法留下了无效状态，这会对第一个方法的行为产生不利影响？如果我理解正确，那么您不应该依赖测试执行的顺序。

我可以想象的其他失败包括流的非关闭、GDI+ 对象的非处置等。

这甚至是 TDD 的问题域，还是集成和系统测试应该捕获此类问题？

感谢期待....

Answer 1

其中一些属于 TDD 领域。

Dan North 说没有测试驱动开发这样的东西。我们真正在做的是示例驱动的开发，只有在被测系统实现后，示例才成为回归测试。

这意味着在设计一段代码时，您会考虑示例场景并为每个案例设置测试。这些情况应该包括数据无效的可能性，而不考虑数据可能无效的原因。

在实践 TDD 时，可以而且应该绝对涵盖关闭流之类的事情。

我们使用类似函数的构造不仅是为了减少重复，而且是为了封装功能。我们通过保持封装来减少副作用。我认为我们从设计的角度考虑更大的图景，但是当涉及到实现一个方法时，我们应该能够将我们的重点缩小到那个范围——那个功能单元。当我们开始处理外部性时，我们很可能会引入缺陷。

无论如何，这是我的看法；其他人可能会有不同的看法。