《重构 改善既有代码的设计》 读书笔记（十五）

第四章 构筑测试体系

可靠的测试是安全重构的前提。

4.1 自测试代码的价值

一套测试就是一个强大的BUG侦测器，能够大大缩短查找BUG所需要的时间。

但我们都很懂，编写测试代码，意味着额外的时间，额外的精力，除非真正地感受到这种方法对编程速度的提升，否则自我测试是没有意义的。（体现不出它的意义）

在通常情况下，我们的测试是手动运行的，如果测试变得自动化，能够自动告诉错误出现在哪里，那么测试就会变得有趣且有意义了。

撰写测试代码最有用的实际是在开始编写之前——编写测试代码代码其实就是在问自己，这个功能需要做些什么。编写测试代码还能使你把注意力集中于接口而非实现。预先写好的测试代码也为你的工作安上一个明确的结束标志。

在Java中，测试的惯用手法是testing main，意思是每个类都应该有一个用于测试的main()。而另一种做法是，建立一个独立类用于测试，并在一个框架中运行它，使测试工作更轻松。

4.2 JUnit测试框架

从现在起，我们又要开始敲代码了。

声明一点：这本书用的JUnit版本比较古老，而我对JUnit其实不很熟悉，所以大致还是按着书的思路来写，如果有必要的话，我也许会修改。

任何包含测试代码的类都必须继承测试框架所提供的TestCase类。这个框架运用了设计模式之组合模式（Compoeite），允许你将测试代码聚集到测试套件（test suite）中。

组合模式：多用于部分-整体这样的关系。它的目的在于把一类东西聚集起来，在外表现出同样的行为接口。（恕我不能很好地讲出，具体还是网上查+实例比较好）

在本章中，将会创造一个FileReaderTester类来测试文件读取器，它与测试框架的UML类图如下：

/'在线作图（UML）网址：
http://www.plantuml.com/plantuml/uml/SyfFKj2rKt3CoKnELR1Io4ZDoSa70000
如果要修改的的话，打开网址后，直接复制上图片链接（或者粘贴下方代码）修改即可'/
@startuml
Title '测试框架的组合结构'
class FileReaderTester
namespace junit.framework #DDDDDD {
interface Test
TestCase <|- .FileReaderTester
Test <|.. TestCase
Test <|.. TestSuite
Test <- TestSuite
}
@enduml

下面开始建立FileReaderTester类。

public class FileReaderTester extends TestCase {
   
	public FileReaderTester(String name) {
   
		super(name);
	}
}

对于老版本和新版本的JUnit而言，一个很显著的改变是由继承变成注解，如果之后我能提得起兴趣，可能会把较新版本的JUnit也写一遍。

这个新建的类必须有一个构造函数，完成之后就可以开始添加测试代码了。

首先，要设置测试夹具（test fixture），也就是样本。在这里供我们测试的样本是一个文件。

Bradman		99.94	52	80	10	6996	334	29
Pollock		60.97	23	41	4	2256	274	7
Headley		60.83	22	40	4	2256	270*	10
Sutcliffe	60.73	54	84	9	4555	194	16

在进一步运用这个文件之前，需要准备好测试夹具。

在JUnit中的TestCase类提供两个函数针对此用途：setUp()用来产生相关对象，tearDown()负责删除它们。

我们需要在我们的测试类中对这两个方法进行覆写。（在TestCase类中并没有为这两个方法附带代码）