对于不了解测试驱动开发的开发人员，采用TDD会解决哪些问题？
[编辑]让我们假设开发人员已经（ab）使用单元测试框架。
以下是TDD可能对开发人员/团队有所帮助的三个原因：
首先编写测试的一个原因是在编写之前更好地理解实际代码。对我而言，这是测试驱动开发的主要好处。当您首先编写测试用例时，您会更加批判性地考虑角落情况。在编写代码并确保它们准确时，更容易解决它们。
另一个原因是实际执行编写测试。通常当人们在没有TDD的情况下进行单元测试时，他们会设置测试框架，编写一些新代码，然后退出。他们认为代码已经运行得很好，为什么要编写测试呢？这很简单，它不会破坏，对吗？但是现在你已经失去了首先进行单元测试的优势（完全不同的讨论）。先写下它们，它们已经存在了。
首先编写这些测试可能意味着您不需要在调试环境中启动该程序（特别是对于较大的项目而言），以测试是否有一些小的工作。当然，在进行更改之前没有理由不这样做。
说服自己或其他人先写测试可能很困难。你可能有更好的运气让他们同时写两篇文章，这可能同样有益。
众所周知，编写测试和进行大量自动化测试是一件好事。
但是，如果没有TDD，它通常会变得单调乏味。人们编写测试，然后离开它，测试不会像他们应该那样得到更新，也不会像他们应该那样经常测试新功能。
其中很大一部分原因是因为代码变得很难测试--TDD会影响你的设计，因此它更容易测试。因为您使用过TDD，所以您可以进行大量的测试，这样可以在代码或需求发生变化时更容易找到回归，从而大大简化调试，获得良好的TDD，并鼓励在更改时编写更多测试需要 - 我们回到了周期的开始。
有许多优点：
任何这些都足以证明实施TDD。
大概是你在将它提交到存储库之前测试了你编写的代码。
如果那不是真的，你还有其他问题要处理。
如果确实如此，您可以使用框架来编写测试，以便自动化当前编写的主要例程或驱动程序，这样您只需按一下按钮就可以自动运行所有这些例程或驱动程序。您不必仔细考虑输出以确定测试是通过还是失败;您将测试的成功或失败嵌入到代码中，并立即做出竖起或下降的决定。一次运行所有测试可以减少“敲打鼹鼠”的可能性，在这种情况下，您可以在一个类中修复某些内容并破坏其他内容。所有的测试都必须通过。
听起来不错，是吗？
TDD人员要求你在写完课程之前先写下测试FIRST，然后再向前迈进一步。当然，它失败了，因为你没有写过这门课。这是他们保证你编写测试类的方法。
如果您已经在使用测试框架，从您编写的测试中获得良好的价值，并且有意义的代码覆盖率达到70％左右，那么我认为您做得很好。我不确定TDD会给你更多的价值。由你来决定你是否加倍努力。就个人而言，我不这样做。如果我认为有需要，我会在课后编写测试并重构。有些人可能会发现在首先知道它会失败的情况下编写测试会有所帮助，但事实并非如此。
（这更像是一个评论，同意duffymo的答案，而不是自己的答案。）
duffymo答案：
TDD人员要求你在写完课程之前先写下测试FIRST，然后再向前迈进一步。当然，它失败了，因为你没有写过这门课。这是他们保证你编写测试类的方法。
我认为这实际上是迫使程序员考虑他们的代码在做什么。必须考虑测试才能考虑代码应该做什么：前置条件和后置条件是什么，哪些函数是原始的，哪些是由原始函数组成的，最小的必要公共接口是什么，以及什么是一个实现细节。
这些都是我经常考虑的事情，所以像你一样，“先测试”对我来说并没有增加太多。坦率地说（我知道这在某些圈子里是异端）我喜欢先勾勒出公共界面，然后“锚定”一个类的核心思想;通过这种方式，我可以看一下，精神上使用它，看看它是否像我想象的那样干净。 （类或库应该简单直观，供客户端程序员使用。）
换句话说，我做的是TDD尝试通过首先编写测试来确保发生，但是像duffymo一样，我以不同的方式实现目标。
而“先测试”的真正意义在于让编码人员像设计师一样停下来思考。嘲笑程序员如何进入该状态是愚蠢的;对于那些不自然地做到这一点的人来说，“先测试”可以作为让他们到达那里的仪式。对于那些做过的人来说，“先测试”并没有增加多少 - 并且可能妨碍程序员习惯性地进入该状态。
同样，我们想要看结果，而不是仪式。如果一个初级人需要一个仪式，一个“十字架”或一个念珠*来“陷入困境”，“先测试”就是为了这个目的。如果有人有自己的方式也到那里，那也很棒。
请注意，我并不是说不应该测试代码。这应该。它为我们提供了一个安全网，这反过来又使我们能够集中精力编写好的代码，甚至是大胆的代码，因为我们知道网络可以捕获错误。
我所说的是，对“先测试”的拜物教坚持将这种方法（许多方法之一）与目标混为一谈，使程序员思考他正在编码的内容。
*为了普及，我会注意到天主教徒和穆斯林都使用念珠。而且，这是一种机械的，肌肉记忆的方式，使自己进入某种心境。这是一种迷信（在原始意义上的魔法物体，而不是“性迷信”的意思）或好运的魅力。所以说“Om mani padme hum”，或者坐着zazen，或者抚摸着一只“幸运的”兔子的脚（对兔子来说不是那么幸运。）哲学家Jerry Fodor在考虑难题时也有类似的仪式：他重复一遍对自己说，“来吧，杰里，你能做到！” （我也试过了，但因为我的名字不是杰瑞，所以它对我不起作用。;））
理想的情况是：
您不会浪费时间编写您不需要的功能。您将拥有一个全面的单元测试套件，作为重构的安全网。您将获得有关如何使用代码的可执行示例。您的开发流程将更加顺畅和快速;你会花更少的时间在调试器上。
但最重要的是，您的设计会更好。您的代码将更好地考虑因素 - 松散耦合，高度内聚 - 以及更好的形成 - 更小，更好命名的方法和类。
对于我目前的项目（运行相对较重的过程），我采用了一种特殊形式的TDD，包括根据需求文档和GUI模型编写框架测试用例。在开始实现任何东西之前，我写了几十个，有时几百个（这完全违背了“纯”TDD，它说你应该编写一些测试，然后立即开始一个骨架实现）。
我发现这是查看需求文档的绝佳方法。我必须更加深入地考虑他们所描述的行为，而不是仅仅是为了阅读它们。因此，我发现其中存在更多的不一致和差距，否则我将在实施过程中找到这些差异和差距。这样，我可以提前要求澄清，并在开始实施时有更好的要求。
然后，在实施过程中，测试是一种衡量我尚未走多远的方法。它们阻止我忘记任何事情（不要笑，当你处理更大的用例时，这是一个真正的问题）。
道德是：即使你的开发过程不能真正支持TDD，它仍然可以通过某种方式完成，并提高质量和生产力。
我个人不使用TDD，但是我能用方法论看到的最大的专业人员之一是客户满意度保证。基本上，我们的想法是您的开发过程的步骤如下：
1）与客户讨论应用程序应该做什么，以及应该如何应对不同情况。
2）将1）的结果转换为单元测试，每个单元测试测试一个特征或场景。
3）编写简单的“草率”代码（几乎没有）通过测试。完成后，您就满足了客户的期望。
4）重构你在3）中写的代码，直到你认为你已经以最有效的方式完成它。
完成后，您可以生成高质量的代码，满足客户的需求。如果客户现在想要一个新功能，那么就开始循环 - 讨论该功能，编写一个确保它可行的测试，编写通过测试的代码，重构。
正如其他人所说，每次运行测试时，都要确保旧代码仍然有效，并且可以添加新功能而不会破坏旧代码。
我谈过的大多数人都没有使用完整的TDD模型。他们通常会找到最适合他们的测试模型。找到你的TDD游戏，找到你最有效率的地方。
我花了很大力气学习Ruby on Rails开发的TDD。我真的进入它之前需要几天时间。我非常怀疑，但我努力，因为我尊重的程序员支持它。
在这一点上，我觉得这绝对值得努力。有几个好处，我相信其他人会很乐意为您列出。对我来说，最重要的优势在于它有助于避免在一个项目后期出现噩梦般的情况，在这个项目中，某些东西突然中断，没有明显的原因，然后你花了一天半的时间使用调试器。当您向其添加越来越多的逻辑时，它有助于防止您的代码库恶化。
TDD（测试驱动开发/设计）具有以下优点
因此，您最终得到的代码就是