Question

我一直在努力坚持TDD方法。所以我做了一些测试，但都失败了。现在我正在实施。但是现在我正在实现我已经看到这些方法太简单而不能失败。特别是我实现了观察者模式，所有发生的事情是我通知所有注册的观察者。因此，对每个循环使用a并调用notify。这当然听起来太简单了。既然我在某些地方进行了测试，我应该删除它们吗？这似乎也有点浪费时间。那么我应该尝试预测一些过于简单的方法吗？

Answer 1

没有

这些方法现在可能过于简单而无法破解，但这并不意味着将来永远不需要修改（也可能会被破坏）。

Answer 2

是;如果您正在测试底层编译器/虚拟机的功能，那么您的测试太简单了。除非，也就是说，您不相信正在运行的编译器/虚拟机的特定部分。

但是，当然，测试的现实比这个问题的答案是肯定/否定更复杂。如另一个答案所述，如果您已经编写了测试，请不要删除它们。但是你也不应该在代码覆盖率上下文中使用它们作为信心的论据。

Answer 3

你说这太简单了，不能失败：

for (i = 0; i < observers.length; ++i) {
    // Notify observer observers[i]
}

这很容易想到，但考虑到这个常见的错误：

for (i = 0; i <= observers.length; ++i) {
    // Notify observer observers[i]
}

或者这个：

for (i = 0; i < observers.length; ++j) {
    // Notify observer observers[i]
}

或者观察者可能没有正确添加。或者...或者...或者...

如果你已经有了测试，似乎没有必要删除它们，而且软件的一个公理是功能随着时间的推移而增长，所以简单的现在可能不那么简单了 - line - 正是你的测试应该帮助你的那种东西。

Answer 4

没有

你做得非常正确：编写首先失败的测试，然后修复它们。如果您认为自己需要它们（例如重现错误），请将这些测试单独留下，将来编写更复杂的测试。

Answer 5

你的测试越多，你将来的痛苦就越小。没关系他们的简单。

Answer 6

现在你已经完成了所有这些测试，让他们独自一人。如果他们跑得足够快，他们就不会成为任何人的负担。

但是，将来，您可能希望一次只编写一个失败的测试。（见The Three Rules）。这是因为它可以在您开发代码时改进设计。

如果您的所有测试都失败并且没有实施，那么您已经修复了设计，现在它的工作原理可能会让您厌恶重构设计以改进它。

我还怀疑你在执行代码时遇到了一些棘手的问题，因为每个实现步骤可能会破坏比通过更多的测试，但是嘿，我只是在猜测！

我们是否应该删除在TDD期间过于简单而无法破解的测试

6 个答案: