我最近一直在阅读关于TDD的内容，并且它被提倡，因为它可能导致代码更易测试且耦合性更低（以及其他一些原因）。
除了Roman numeral conversion和number-to-English converter之外，我在实际示例中找不到太多。
观察这两个例子，我观察了TDD典型的典型红 - 绿 - 重构循环，以及rules of TDD的应用。然而，这似乎是浪费时间，通常我会观察一个模式并在代码中实现它，然后为它编写测试。或者可能为代码编写存根，编写单元测试，然后编写实现 - 可能可能是TDD - 但不是这种连续的逐个案例重构。
TDD似乎煽动开发人员直接进入代码并以感应方式构建他们的实现，而不是设计合适的架构。到目前为止，我的观点是TDD的好处可以通过适当的架构设计来实现，尽管不是每个人都能很好地做到这一点。所以我在这里有两个问题：
答案 0 :(得分：0)
我可以在这些方面总结我对TDD的体验：
TDD是正确的单元测试，ATDD / BDD是TDD完成的。
您事先是否设计完全取决于您。请确保您没有BDUF。相信我，你最终会在中途改变大部分内容，因为在你的手弄脏之前，你永远无法完全理解这些要求
OTOH，你可以做足够的设计来帮助你入门。只要你没有在设计阶段挂起来试图弄清楚一切，那么类图，序列图，领域模型，演员和合作者都是完美的。
有些人根本不做任何设计。他们只是让代码说话并专注于重构
恕我直言，平衡你的方法。做一些设计，直到你掌握它然后开始测试。当你到达死胡同然后回到白板
还有一件事，像figuring out an algorithm这样的TDD无法解决一些问题。这是一篇非常有趣的帖子，表明有些事情需要先设计。
当您拥有代码时，单元测试很难。 TDD迫使您从API用户的角度思考问题。这样您就可以尽早确定API中的公共接口是否可用。如果你决定在实现所有内容之后进行单元测试，你会觉得它很乏味，而且很可能只会出现在某些情况下，我知道有些人只会通过测试用例才能完成这项功能。我是说谁想在完成所有工作后打破自己的代码？ TDD打破了这种心态。测试是一等公民。您不能跳过测试。由于我们没有足够的时间，因此您不能将某些测试推迟到下一个版本。
最后回答你的问题，如果TDD给你的任何东西，你在开始编码之前无法做出正确的设计，我会说承诺。
只要您执行TDD，您就致力于应用良好的OO原则，以便您的代码可以测试。
答案 1 :(得分：0)
回答你的问题：
“测试驱动开发”（TDD）通常被称为“测试驱动设计”，因为这种做法将导致良好的代码设计。当您编写了一个失败的单元测试时，您将被迫采用测试驱动的设计方法，这样您就可以实现使测试通过所需的内容，即您必须考虑代码的设计你正在写作试验通过。
使用TDD方法时，开发人员将实现通过测试所需的最少代码量。如果项目开始后需求发生变化，事先进行适当的设计通常会导致浪费。
你说“TDD似乎煽动开发人员直接进入代码并以感应方式构建他们的实现，而不是设计一个合适的架构” - 如果你正在遵循敏捷方法进行软件开发，那么你仍然需要做一些前期架构调查（例如，如果您使用Scrum方法，您将在项目开始时创建开发“Spike”）以确定启动项目所需的最小架构数量。在此阶段，您可以根据您现在知道的内容做出决定，例如：如果您必须使用小型数据集，则选择使用常规数据库，如果您拥有庞大的数据库，则可以选择使用NoSQL大数据数据库等。
然而，一旦你对架构有一个大概的了解，你就应该让设计随着项目的进展而发展，尽可能在后期进行更多的架构决策;随着项目的进展，架构和需求将不断变化。
此外，在SO上相当受欢迎的post将为您提供更多理由，说明为什么TDD绝对值得付出努力。