我最近一直在阅读有关TDD的文章，它之所以被提倡，是因为它应该导致代码更易于测试且耦合更少(以及一堆其他原因(。
除了罗马数字转换和数字到英语转换器之外，我找不到太多实际示例。
观察这两个例子，我观察了TDD典型的红-绿-重构循环，以及TDD规则的应用。但是，这似乎是浪费时间，而通常我会观察一种模式并在代码中实现它，然后为它编写测试。或者可能为代码编写存根，编写单元测试，然后编写实现 - 可以说是TDD - 但不是这种连续的逐案重构。
TDD似乎鼓励开发人员直接跳入代码并以归纳方式构建他们的实现，而不是设计适当的架构。到目前为止，我的观点是，TDD的好处可以通过适当的架构设计来实现，尽管不可否认，并不是每个人都能做得相当好。
所以在这里我有两个问题：
- 我是否正确理解使用TDD几乎
- 不允许你首先设计(参见TDD的规则(？
- TDD给你的东西是你在开始编码之前做正确的设计无法得到的吗？
好吧，我前段时间站在你的立场上，也有同样的问题。从那以后，我读了很多关于TDD的文章，并决定稍微搞砸一下。
我可以在以下几点中总结我对TDD的经验：
-
TDD是正确完成的单元测试，ATDD/BDD是TDD正确完成的。
-
是否事先设计完全取决于您。只要确保你不做 BDUF。相信我，你最终会在中途改变大部分内容，因为在你的手变脏之前，你永远无法完全理解要求。
OTOH，你可以做足够的设计来让你开始。类图，序列图，领域模型，参与者和协作者是完全没问题的，只要你不要在设计阶段试图弄清楚所有事情。
有些人根本不做任何设计。他们只是让代码说话并专注于重构。
恕我直言，平衡你的方法。做一些设计，直到你掌握了窍门，然后开始测试。当你到达死胡同时，然后回到白板。
还有一件事，有些事情不能通过TDD解决，比如找出一个算法。这是一个非常有趣的帖子，表明有些东西只需要先设计。 -
当你已经有了代码时，单元测试是困难的。TDD 迫使您从 API 用户的角度思考。通过这种方式，您可以尽早确定 API 中的公共接口是否可用。如果你决定在实现所有内容后进行单元测试，你会发现它很乏味，而且很可能只适用于某些情况，我知道有些人只会为了完成功能而通过测试用例。我的意思是，在所有这些工作之后，谁想破坏自己的代码？
TDD打破了这种心态。考试是一等公民。您不得跳过测试。您不能将某些测试推迟到下一个版本，因为我们没有足够的时间。 -
最后回答你的问题，TDD给你的东西，如果你在开始编码之前做正确的设计是无法得到的，我会说承诺。
只要你做TDD，你就致力于应用良好的OO原则，以便你的代码是可测试的。
要回答您的问题：
- "测试驱动
开发"(TDD(通常被称为"测试驱动设计"，因为这种做法将导致代码的良好设计。当你编写了一个失败的单元测试时，你被迫采用测试驱动的设计方法，这样你就可以实现使测试通过所需的内容，即你必须考虑你正在编写的代码的设计才能使测试通过。
使用 TDD 方法时，开发人员将实现通过测试所需的最少代码量。如果项目开始后需求发生变化，事先进行适当的设计通常会导致浪费。
你说"TDD似乎煽动开发人员直接跳入代码并归纳构建他们的实现，而不是设计一个适当的架构" - 如果你在软件开发中遵循敏捷方法，那么你仍然需要做一些前期的架构调查(例如，如果你使用Scrum方法，你会在项目开始时创建一个开发"Spike"(，以确定架构的最小数量。需要启动项目。在这个阶段，你根据你现在所知道的做出决策，例如，如果你必须使用一个小数据集，你会选择使用常规数据库，如果你有一个巨大的数据库，你可能会选择使用NoSQL大数据数据库等。
但是，一旦您对架构有了大致的了解，您应该让设计随着项目的进展而发展，在流程的后期做出进一步的架构决策;随着项目的进展，架构和需求总是会发生变化。
此外，这篇关于SO的相当受欢迎的帖子将为您提供更多理由，说明TDD绝对值得付出努力。