假设我有一个用户类有一个方法is_old_enough？TDD是否意味着我必须为每种方法编写一个测试，不管它有多复杂？
该方法只是检查年龄超过18岁。看起来很简单。
TDD是否意味着我必须为此写一个测试，即使它很微不足道？
class User
def is_old_enough?
self.age >= 18
end
end
如果是这样，为什么？为此编写测试有什么好处？你只需要测试x> = y是否符合你期望> =操作符的工作方式。
因为我看到的情况是最有可能的情况是：
原来的年龄实际上应该是21.这是该测试没有赶上一个错误，因为他们有错误的假设，当我们写代码。然后他们进入并将方法更改为> = 21。但是现在测试失败！所以他们必须去改变测试。所以测试没有帮助，并且在重构时实际上给出了误报。
看起来像这样简单的方法测试实际上没有测试任何有用的东西，实际上是伤害你。
我觉得你很困惑测试覆盖和测试驱动开发。 TDD只是开发自动化测试的一种做法，它将验证某些新功能的使用情况。通常它开始失败，因为你已经将功能桩出来或者根本没有实现它。接下来，您开发该功能，直到测试通过。
这个想法是，您正在开发验证您的重要用例/功能的测试的心态。这并不一定意味着如果您认为自己被常规功能测试覆盖，则需要测试简单功能。
就覆盖率而言，开发者（或团队）决定是否真的取决于您。很显然，对API进行1对1的测试覆盖率是需要的，但是您可以选择是否认为总是易于实施is_old_enough?。它现在看起来像是一个简单的实施，但也许这将在未来发生变化。当您选择是否编写测试时，您只需要注意这些决定。尽管如此，您的用例不会改变，测试也很容易编写。在代码的所有领域感到自信并没有什么坏处。
我认为这个问题更多的是与单元测试有关，尤其是TDD。
简短的回答：注重行为
龙答：嗯，有一个很好的短语在那里：BDD是TDD做对，我完全同意。尽管BDD和TDD在很大程度上是“相同”的东西（不等于，请注意！），BDD为我提供了TDD的背景。你可以解决这个在网上看了很多，所以我不会在这里写文章，但让我这样说：
难题的一个非常重要的部分是单元测试只是您需要的一种技术。如果你的设计缺乏，你会发现你自己写了太多没有意义的测试，或者你会让地狱测试类做很多事情等。你需要有非常好的SOLID技能，以便能够以仅测试他们的方式公共接口（这也包括受保护的方法）实际上测试整个类。如前所述，关注行为是关键。
我认为“测试驱动”是指你测试你的代码。这并不意味着你必须变得愚蠢。另一方面，有时候相对简单的代码可能会有错误。如果有人在一个地方改变了定义，测试可能会失败。您必须同时进行积极和消极的测试（例如“过关18分，失败17分”）。如果限制更改为16，则您的第二个测试现在将失败。我总是告诉人们：“当你学习新的东西时，不要拔掉常识模块为新信息留出空间”。 – Floris
使用TDD，您不需要为方法编写测试，而是为测试编写一个或多个方法。你首先写一个描述一些理想但尚未实现的行为的测试。然后你写出必要的代码来通过测试。 –