【笔记】《重构：改善既有代码的设计》第4章-构筑测试体系

第4章 构筑测试体系

如果你想进行重构，首要前提就是拥有一个可靠的测试环境。

编写优良的测试程序，可以极大提高我的编程速度，即使不进行重构也是一样如此。

4.1 自测试代码的价值

编写测试程序，意味着要写很多额外代码。除非你确切体验到这种方法对编程速度的提升，否则自我测试就显不出它的意义。

实际上，撰写测试代码的最有用时机是在开始编程之前。当你需要添加特性的时候，先写相应测试代码。听起来离经叛道，其实不然。编写测试代码还能使你把注意力集中于接口而非实现（这永远是件好事）。预先写好的测试代码也为你的工作安上一个明确的结束标志：一旦测试代码正常运行，工作就可以结束了。

频繁进行测试是极限编程的重要一环。

重构前我们首先必须改造这些代码，使其能够自我测试。

Java之中的测试惯用手法是testing main，意思是每个类都应该有一个用于测试的main()。这是一个合理的习惯（尽管并不那么值得赞许），但可能不好操控。这种做法的问题是很难轻松运行多个测试。另一种做法是：建立一个独立类用于测试，并在一个框架中运行它，使测试工作更轻松。

4.2 JUnit 测试框架

（本书所用的JUnit版本已经非常古老，很多用法早已过时。请读者自行下载最新版本的JUnit，并参考相关文档来复现这些例子。——译者注）

第一件工作是设置测试夹具（test fixture），也就是用于测试的对象样本。

频繁地运行测试。每次编译请把测试也考虑进去——每天至少执行每个测试一次

单元测试和功能测试

JUnit框架的用途是单元测试，所以我应该讲讲单元测试（Unit Test）和功能测试（Functional Test）之间的差异。我一直挂在嘴边的其实是单元测试，编写这些测试的目的是为了提高程序员的生产率。 单元测试是高度局部化的东西，每个测试类都隶属于单一包。它能够测试其他包的接口，除此以外它将假设其他包一切正常。

功能测试就完全不同。它们用来保证软件能够正常运作。它们从客户的角度保障质量，并不关心程序员的生产力。它们应该由一个喜欢寻找bug的独立团队来开发。这个团队应该使用重量级工具和技术来帮助自己开发良好的功能测试。

一般而言，功能测试尽可能把整个系统当作一个黑箱。

每当你收到bug报告，请先写一个单元测试来暴露bug。

4.3 添加更多测试

我遵循的风格是：观察类该做的所有事情，然后针对任何一项功能的任何一种可能失败情况，进行测试。这不同于某些程序员提倡的“测试所有public函数”。 我不会去测试那些仅仅读写一个字段的访问函数，因为它们太简单了，不太可能出错。

这一点很重要，因为如果你撰写过多测试，结果往往测试量不够。 测试的要诀是：测试你最担心出错的部分。这样你就能从测试工作中得到最大利益。

编写未臻完善的测试并实际运行，好过对完美测试的无尽等待。

测试的一项重要技巧就是“寻找边界条件”。

考虑可能出错的边界条件，把测试火力集中在那儿。

“寻找边界条件”也包括寻找特殊的、可能导致测试失败的情况。对于文件相关测试，空文件是个不错的边界条件。

随着测试类愈来愈多，你可以生成另外一个类，专门用来包含由其他测试类所组成的测试套件。

当测试数量达到一定程度之后，继续增加测试带来的效益就会呈现递减态势，而非持续递增。

对象技术有个微妙处：继承和多态会让测试变得比较困难，因为将有许多种组合需要测试。

测试代码和产品代码之间有个区别：你可以放心地复制、编辑测试代码。