我最近一直在阅读有关 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 方法，您将在项目开始时创建一个开发“尖峰”）以确定启动项目所需的最少架构数量。在这个阶段，你根据你现在所知道的做出决定，例如，如果你必须使用一个小数据集，你会选择使用常规数据库，如果你有一个巨大的数据库，你可能会选择使用 NoSQL 大数据数据库等.
然而，一旦你对架构有了大致的了解，你应该让设计随着项目的进展而发展，而在过程中尽可能晚地做出进一步的架构决策；随着项目的进展，架构和需求总是会发生变化。
此外，这篇关于 SO 的颇受欢迎的帖子将为您提供更多理由说明 TDD 绝对值得付出努力。