TDD：从单元测试开始，让你的代码更可靠

作者介绍

Bob大叔(Robert Martin)是一位著名的软件工程师、教练、顾问和演说家。他是敏捷开发方法和软件工程领域的知名人物，被誉为“敏捷宣言”的共同起草人之一。

Bob大叔在软件开发领域拥有超过50年的经验，是一位极具影响力的思想领袖。他是《Clean Code》、《Agile Software Development: Principles, Patterns, and Practices》、《The Clean Coder》等多本著作的作者，这些书籍被广泛认为是软件工程领域的经典之作。

Bob大叔在敏捷开发方法的推广和实践方面做出了杰出的贡献。他是Scrum、XP等多个敏捷方法的支持者和实践者，为推动敏捷开发方法的发展和普及做出了重要的贡献。

TDD三个基本原则

多年来，我一直用如下几个简单规则来描述TDD：

1.不允许编写任何产品代码，除非目的是为了让失败的测试通过

2. 不允许编写多于一个的失败测试，编译错误也是失败

3. 不允许编写多于恰好能让测试通过的产品代码。你必须从编写单元测试开始编写你的功能。

但根据规则2，你也不能编写很多单元测试。一旦单元测试编译错误或者断言失败，你必须停下来编写产品代码。但根据规则3，你的产品代码刚好能让测试通过即可，不要编写超过这个范围。

看起来傻但实际有效

如果你想一下，你就会意识到。如果不编译和执行，你就不能写很多代码。确实，这就是TDD的重点。在我们所做的每一件事中，无论是编写测试、编写生产代码还是重构，我们都会让系统一直在执行。运行测试之间的时间大约为秒或分钟。即使10分钟也太长了。

要看这个过程，请参考http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata

大多数的程序员，第一次听到这个技术后第一反应是“这太傻了”。“这会让我的工作变慢，这就是浪费时间和精力，这会让我不思考、不设计。它只会打乱我的流程”。

但是，想想一下你走进一个房间，里面的人都是这种工作方法。任何时间拎起任何一个人，他们的代码1分钟前可以工作。让我再重复一遍：一分钟前所有他们的代码都可以工作！不论你找谁，也不管什么时候，1分钟前他们的代码能工作！

持续测试的好处

如果你的代码每一分钟都可以工作，你会多久用一次调试？答案是不会太频繁。用Ctrl+Z可以很容易回退到上一个能工作的状态，然后把最后一分钟的工作再写一次。如果你不经常调试，你节约了多少时间？你现在用多少时间在调试？你又花了多少时间修改调试发现的Bug？如果你能把这些时间大大缩短呢？但好处远不止于此。

如果你这样工作，那么每小时你都要做几次测试。每天都要写几十个测试。每个月写数百个测试。在一年的时间里，你将写成千上万的测试。你可以保留所有这些测试，并随时运行它们！你什么时候来运行他们？随时！任何时候你改变代码的时候！为什么我们不清理那些我们知道很乱的代码呢？我们怕弄坏它。但是如果我们有测试，我们可以有理由确定代码没有被破坏，或者我们将立即检测到破坏。如果我们有了测试，我们就会无所畏惧地做出改变。

如果我们看到凌乱的代码，或者不干净的结构，我们可以毫无畏惧地清理它。由于测试，代码再次变得可扩展。由于测试，软件再次变得软。但好处远不止于此。如果你想知道如何调用一个特定的api，有一个测试可以做到这一点。

如果你想知道如何创建一个特定的对象，有一个测试可以做到。任何你想知道的关于现有系统的信息，都有一个测试来演示。测试就像一个小的设计文档，一个小的编码示例，描述了系统的工作原理和使用方法。您是否曾将第三方库集成到您的项目中？你有一本编写的很好很厚的用户手册，手册最后有一个很薄的例子附录。你会读哪部分？当然是例子！这就是单元测试！它们是文档中最有用的部分。它们是如何使用代码的活生生的例子。它们是设计文档，非常详细，完全不含糊，如此正式以至于它们可以执行，并且它们不可能与生产代码不同步。

但好处远不止于此。如果您曾经试图将单元测试添加到一个已经在工作的系统中，您可能会发现它并不是很有趣。您可能会发现，您要么必须更改系统设计的某些部分，要么在测试中作弊；因为您试图为其编写测试的系统不是设计为可测试的。例如，您想测试某个函数“f”。但是，’f’调用另一个函数从数据库中删除记录。在你的测试中，你不想删除记录，但你没有任何方法阻止它。这个系统不是为测试而设计的。

当您遵循TDD的三个规则时，您的所有代码都是可测试的！“可测试”的另一个词是“解耦”。为了单独测试模块，必须将其分离。所以TDD强迫你分离模块。事实上，如果你遵循这三条规则，你会发现自己过去做的要更加解耦。这迫使您创建更好的、更少耦合的设计。考虑到所有这些缺陷，TDD的这些愚蠢的小规则实际上可能并不那么愚蠢。它们实际上可能是一些基础性的、深刻的东西。

实际上，在我接触到TDD之前，我已经做了将近30年的程序员。我不认为有人能教我一个能带来不同的低水平的编程实践。三十年毕竟是很多经验。但当我开始使用TDD时，我对这种技术的有效性感到目瞪口呆。我也被迷住了。我再也忍不住输入一大堆希望它能工作的代码了。我再也不能忍受把一组模块拆开，希望在下周五之前把它们重新组装好，让它们全部工作。我在编程时所做的每一个决定都是由一分钟后再次执行的基本需求驱动的。

参考来源：http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

END

通过TDD的这些基本规则，程序员们可以在编写代码时更加高效和可靠。但是，这只是敏捷软件开发方法中的一部分。

如果你想更加深入地了解如何通过敏捷开发方法来提高软件开发效率和质量，快来加入我们即将开课的敏捷CSD认证公开课吧！我们的敏捷CSD认证课程是由一群经验丰富的敏捷教练、咨询师设计的，旨在帮助软件开发人员和团队掌握敏捷开发方法和技术。

我们的课程内容涵盖了Scrum框架、TDD、持续集成、持续交付、用户故事、迭代计划等方面的内容，以及如何在团队中使用这些技术和方法。我们的课程采用了互动式教学方法，让学员通过实践来掌握敏捷开发方法和技术。

我们的教练将为学员提供实时反馈和指导，帮助克服在实践中遇到的挑战和问题。现在，扫描海报二维码，即可了解课程详情哦！