《Effective Unit Testing》 读书笔记 1 作为质量工具和设计工具的测试

    因为需要提高团队代码质量，暂时换个口味读本讲Unit Test的书。这本书全名 Effective Unit Testing  A guide for Java Developers. 作为读书笔记，我只记录一些个人感觉比较有价值的观点。

Part 1 Foundations （第一部分，基础）

    全书第一部分有三章。作者认为现在（本书出版于2013年）写Unit Test其实是一种业界规范了，所以关键不是要不要写test的问题，而是如何写好的test。前三章阐述了为什么要写好的Test，怎么算是好的Test，还有专门一章讲了Test Doubles(测试替身，作者还细分成fake, mock，stub，spy四种，等待后文详述)的问题。

    从test这个名字出发，大部分人的想法是为了抓住程序中的错误，从另一个方面来说，就是用来验证程序的正确行为 （思考BDD）。更高层次的目的，是通过测试来驱动好的设计。此处插一句，从这两个目的来看，虽然我们应该追求覆盖率，但是就算百分之一百的代码覆盖率也只能说明通过测试代码运行了这些代码，不能说明测试真正验证代码应有的行为。

    测试写得越来越多，测试带来的价值似乎就越来越小，作者用了一张图来描述这种边际效用递减效应（高原效应）。横轴是花在写测试上的精力，纵轴是产生的价值，两条线曲线实线代表作为质量工具的测试，虚线代表作为设计工具的测试。大部分团队其实停留在把测试作为质量保证工具上，作者想说明的是我们应当努力把测试作为设计工具，才能移动到上一条曲线，收获测试给我们带来的更大的价值。

边际效用递减

    作者提出了他的理论：The biggest value of writing a test lies not in the resulting test but in what we learn from writing it. (写测试最大的价值不在于写出来的测试，而在于从写测试过程中所学到的东西)。

    开发者在忽视作为设计工具的测试的同时，也忽视了维护越来越庞大的测试的成本。如何减小这个成本，后文会详述，这里作者提出了一个我认为十分重要的也是容易被我们忽略的观点，要像对待产品代码一样来严肃对待测试代码。好的测试代码本身需要下功夫去设计，好的测试代码必须也要考虑可维护性，在test中也存在技术债的问题。

    测试可以影响开发效率，要提高开发效率，作者认为需要  1. 缩短反馈的时间。 2. 减少debug（包括运行调试模式和修bug）的时间。 

    这里作者提出了test的四个属性，以及这些属性是如何影响开发效率的， a. 通过加快test的执行速度， 可以缩短反馈时间。b. 提高test的可读性，可以减少调试的时间和减少bug。 c. 提高test的可信性（Trustworthiness ），提高测试结果的准确性，从而减少bug。 d. 提高测试的可靠性（可重复运行），提高测试结果的准确性，从而减少bug。通过对这四个属性的增强，我们才能在作为质量工具的test上突破高原效应。

    另一方面，作为设计工具的test要求我们 1. 把测试像产品代码一样，不断重构，保持高的测试代码质量和设计，减少编写， 维护， 运行这些测试的成本 。 2. 通过测试来驱动产品代码的设计（TDD）。本书主要讲如何写出好的测试，所以将聚焦在第一点上。如何通过测试去驱动产品代码的设计不是本书的重点。