### 自我测试代码的价值 如果认真观察程序员把最多时间耗在哪里，你就会发现，编写代码其实只占非常小的一部分。有些时间用来决定下一步干什么，另一些时间花在设计上面，最多的时间则是用来调试（debug)。我敢肯定每一位读者都还记得自己花在调试上面的无数个小时，无数次通宵达旦。每个程序员都能讲出「花一整天（甚至更多）时间只找出一只小小臭虫」的故事。修复错误通常是比较快的，但找出错误却是噩梦一场。当你修好一个错误，总是会有另一个错误出现，而且肯定要很久以后才会注意到它。 彼时你又要花上大把时间去寻找它。 我走上「自我测试代码」这条路，肇因于1992年OOPSLA大会上的一次演讲。会场上有人（我记得好像是Dave Thomas）说：『class应该包含它们自己的测试代码。』这激发了我的灵感，让我想到一种组织测试的好方法。我这样解释它：每个class都应该有一个测试函数，并以它来测试自己这个class。 那时候我还着迷于增量式开发（incremental development），所以我尝试在结束每次增量时，为每个class添加测试。当时我开发的项目很小，所以我们大约每周增量 一次。执行测试变得相当直率，但尽管如此，做这些测试还是很烦人，因为每个测试都把结果输出到控制台（console），而我必须逐一检查它们。我是个很懒的人，我情愿当下努力工作以免除日后的工作。我意识到我其实完全不必自己盯着屏幕检 验测试所得信息是否正确，我大可让计算机来帮我做这件事。我需要做的就是把我所期望的输出放进测试代码中，然后做一个比较就行了。于是我可以舒服地执行每 个的测试函数，如果一切都没问题，屏幕上就只出现一个“OK“。现在，这些classes都变成「自我测试」了。 TIP：确保所有测试都完全自动化，让它们检查自己的测试结果。 此后再进行测试就简单多了，和编译一样简单。于是我开始在每次编译之后都进行测试。很快我发现自己的生产性能大大提高。我意识到那是因为我没有花太多时间 去调试。如果我不小心引入一个可被原测试捕捉到的错误，那么只要我执行测试，它就会向我报告这个错误。由于测试本来是可以正常运行的，所以我知道这个错误必定是在前一次执行测试后引入。由于我频繁地进行测试，每次测试都在不久之前，因此我知道错误的源头就是我刚刚写下的代码。而由于我对那段代码记忆犹新，份量也很小，所以轻松就能找到错误。从前需要一小时甚至更多时间才能找到的错误, 现在最多只需两分钟就找到了。之所以能够拥有如此强大的侦错能力，不仅仅因为我构筑了self-testing classes（自我测试类），也因为我频繁地运行它们。 注意到这一点后，我对测试的积极性更高了。我不再等待每次增量结束，只要写好 一点功能，我就立即添加测试。每天我都会添加一些新功能，同时也添加相应的测试。那些日子里，我很少花一分钟以上的时间在调试上面。 TIP：一整组（a suite of）测试就是一个强大的「臭虫」侦测器，能够大大缩减查找「臭虫」所耑要的时间。 当然，说服别人也这么做，并不容易。编写测试程序，意味要写很多额外代码。除非你确切体验到这种方法对编程速度的提升，否则自我测试就显不出它的意义。很多人根本没学过如何编写测试程序，甚至根本没考虑过测试，这对于编写自我测试代码也很不利。如果需要手动运行测试，那更是令人烦闷欲呕；但如果可以自动运行，编写测试代码就真的很有趣。 实际上，撰写测试代码的最有用时机是在开始编程之前。当你需要添加特性的时候，先写相应测试代码。听起来离经叛道，其实不然。编写测试代码其实就是在问自己：添加这个功能需要做些什么。编写测试代码还能使你把注意力集中于接口而非实现上头（这永远是件好事）。预先写好的测试代码也为你的工作安上一个明确的结束标志：一旦测试代码正常运行，工作就可以结束了。 「频繁进行测试」是极限编程（ extreme programming XP）[Beck, XP]的重要一 环。「极限编程」一词容易让人联想起那些编码飞快、自由而散漫的黑客（hackers)， 实际上极限编程者都是十分专注的测试者。他们希望尽可能快速开发软件，而他们也知道「测试」可协助他们尽可能快速地前进。 争论至此可休矣。尽管我相信每个人都可以从编写自我测试代码中受益，但这并不是本书重点。本书谈的是重构，而重构需要测试。如果你想重构，你就必须编写测 试代码。本章将教你「以Java编写测试代码」的起步知识。这不是一本专讲测试的 书，所以我不想讲得太仔细。但我发现，少量测试就足以带来惊人的利益。 和本书其他内容一样，我以实例来介绍测试手法。开发软件的时候，我一边撰写代 码，一边撰写测试代码。但是当我和他人并肩重构时，往往得面对许多无自我测试的代码。所以重构之前我们首先必须把这些代码改造为「自我测试」。 Java之中的测试惯用手法是“ testing main”，意思是每个class都应该有一个用于测试的main()。这是一个合理的习惯（尽管并不那么值得称许），但可能不好操控。这种作法的问题是很难轻松运行多个测试。另一种作法是：建立一个独立用 于测试，并在一个框架（framework）中运行它，使测试工作更轻松。