自动化测试

那么如何保证重构不破坏既有的功能？答曰：测试。无论你是单元测试，功能测试，集成测试，还是哔哩哔哩测试，总之你需要尽一切可能去测试。重构有一个个「点」（细胞）的重构，所以你需要单元测试；也有一个个「切面」（器官）的重构，所以你需要功能测试；当「切面」的改动甚大（器官移植），还需要集成测试…相关的测试是否存在决定了你能否重构；而测试所花费的时间直接决定了你是否会进行重构，以及以一个什么样的频率进行重构。如果重构了十行代码，却需要花费一个小时进行运行一次单元测试，那么你要么不会去重构代码，要么你重构了不会去测试。

好的重构发生在构建系统的每时每刻，而非问题发生或者老板要求。如果重构之后测试立刻会告知你结果，你会更有信心进行更多的重构，使其成为你工作生活的一部分。

你也许会质疑：什么样的单元测试可能会需要一个小时来完成？答曰：手工测试。这是为什么先验条件不是「测试」，而是「自动化测试」。没有自动化测试（以下简称测试），谈重构纯属扯淡。如果要重构的环节测试覆盖率不好，先想法提高覆盖率。

如何分配测试精力？

单元测试一般是开发人员最应该关注的事情，单元测试只是测试一个方法单元，他不是测试整个流程没有问题。例如它不是测试汽车有没有问题，而是仅仅测试轮胎有没有问题。就像我们学单词以前，都要先学习音标。当然每部分没有问题不能说明整个没有问题，可能衔接、依赖有问题呢？而单元测试会比较完整的测试每个单元的各种不同情况、临界等等。一般来说，如果每个环节都没问题，对应整个流程来说成功概率就会很高，至少在通往成功的路上。

有种这方面的理论叫做 Test Pyramid, 如下图：

主要理念就是，单元测试时基础，我们最应该花时间的地方，而集成测试应该是冰山上的一小部分。why? 主要原因是集成测试比较麻烦，运行起来比较慢，发现的 Bug 少，对于改善代码质量上面起不到任何作用，由于它的重要程度并不那么高，相反单元测试运行速度超快，能发现的bug更多，在开发时能引导更好的代码设计，在重构时能保证重构的正确性，因此它能保证我们的代码在一个比较高的质量水平上。所以大量的集成测试一般会放在测试部门那边去做。至少我们是这样做的，当然对应服务器开发来说，还要有压力测试，对应 Android 开发来说意义不大。

TODO 测试驱动开发

在测试驱动开发（TDD）这本书也写到，如何利用测试驱动开发。

总结

然而由于大环境问题，大家都赶着上线，自动化测试内功这一块，很多忽略的，大部分测试靠人肉。特别是移动开发来说，好多都在嘴上说，「天下武功为快不破」，当我听到这样的话，就想将他拉出去枪毙了，快是够快，就是出问题给他擦屁股时候很难擦。

子曰：读万卷书不如行万里路。行动起来吧，用实践说话，实践是检验真理的唯一标准。如果根本没有测试用例，请先做好这个基本功再谈重构。