当谈到测试驱动开发(以下简称为“TDD”)时，业内工程师对它有一定程度的了解，并且TDD的优势得到了普遍认可。一些研究机构对微软和IBM的八个开发团队进行了对比测试，发现使用TDD的团队与不使用TDD的团队相比，问题发生率降低了40%-90%。在结对编程的相关实验中，使用TDD的组的黑盒测试通过率比不使用TDD的组高18%，效果相当明显。然而，与我们在日常生活中所接触到的实际工作相比，TDD很少被使用，它的价值也被代码农民所混淆。甚至有大咖啡在网上写文章，公开讨论反对它的意见。为什么？不久前，我在融云的一个项目中碰巧有一个小规模的实践，所以我试图结合各方的观点，大胆地谈谈我自己的经历。首先，什么是TDD？TDD首先由肯特·贝克提出，并在他的书《《Test-Driven Development By Example》》中进行了详细的解释(肯特·贝克也是极限编程概念的作者)。正如书中所述，TDD是一种以测试为开发过程中心的软件工程方法，它要求在编写任何产品代码之前，首先要编写用于定义产品代码行为的测试，编写的产品代码应该以通过测试为目标，从而构建简单、清晰、高质量的代码。测试是保证软件质量的重要手段。一个公司的R&D部门通常有很大比例的测试团队作为质量保证的坚实后盾。那么，作为一个开发人员，你能只关心编写代码的进度，并且在运行几次之后提交代码而没有任何问题吗？当初始条件稍有变化或者外部因素如压力和并发性稍有变化时，这样的程序会崩溃吗？一些团队将制定规则和条例，要求为完成的代码编写测试用例，这些代码必须在提交之前通过。这可能会在一定程度上改善情况，但实际效果真的那么明显吗？我听到有人抱怨说，在代码完成后编写测试用例是浪费时间，因为逻辑趋势已经被很好地理解了，测试中不会有重大错误。那时最好多写几行代码，因为有一个测试团队。乍一看，这听起来很合理，但仔细想想，你实际上是在逃避责任，浪费公司资源。确保软件质量的最好方法是什么？让我们看看TDD是如何工作的。如前所述，TDD的本质在于将测试放在前面。这个看似微不足道的变化会带来什么样的化学反应？首先，目的可以明确界定。在编写产品代码之前，您必须首先考虑这部分逻辑的输入和输出是什么，然后写