重构笔记——构筑测试体系

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/pistolove/article/details/42167015

本文是在学习中的总结,欢迎转载但请注明出处:http://blog.csdn.net/pistolove/article/details/42167015


        作为一名程序员,不知你是否在开发过程中也很少甚至不写测试程序,可能大多数人觉得这很正常,其实从个人角度来看也很正常,因为毕竟有测试人员专门进行测试的嘛!但是,如果能够认真观察程序员把最多时间耗在哪里,你就会发现,编写代码其实只占非常小的一部分。有些时间用来决定下一步干什么,另一些时间花在设计上,最多的时间则是用来调试。我敢肯定每一位读者都还记得自己花在调试上的无数个小时,无数次通宵达旦。每个程序员都能讲出花一天(甚至更多)时间只为找出一个小问题的故事。修复错误通常是很快的,但找出错误却是噩梦一场。当你修好一个错误时,总会有另一个错误出现,而且肯定要很久以后才会注意到它。那时你又得花时间去寻找它。看来我们真的有必要构筑测试体系了。


(Ⅰ)自测试代码的价值

        其实,如果认真观察程序员把最多时间耗在哪里,你就会发现,编写代码其实只占非常小的一部分。有些时间用来决定下一步干什么,另一些时间花在设计上,最多的时间则是用来调试。我敢肯定每一位读者都还记得自己花在调试上的无数个小时,无数次通宵达旦。每个程序员都能讲出花一天(甚至更多)时间只为找出一个小问题的故事。修复错误通常是很快的,但找出错误却是噩梦一场。当你修好一个错误时,总会有另一个错误出现,而且肯定要很久以后才会注意到它。那时你又得花时间去寻找它。

        所以,我们应该以长远的眼光来看待问题,而不能为了一时的方便造成以后的诸多不便。就像我们经常会对自己说:“呃,还不错,看起来已经能正常工作了,然后把已开发的代码仍在一边接着开发其它内容”。真的能正常工作?你亲眼看见它正常工作了吗?你测试过了吗?我们经常会自欺欺人,可能也不得不自欺欺人,因为开发人员哪有那么多时间的呀!但是,我们还是应该构筑测试体系,找出其中的问题。然而,编写优良的测试程序代码,可以极大提高我的编程速度,即使不进行重构也一样如此。

        我觉得每个类都应该有一个测试函数,并以它来测试自己这个类。一般情况下,我们都会进行增量式开发,所以在结束每次增量时,最好能够为每个类添加测试,以确保正确性。就像之前在开发的项目比较小的时候,大约每周增量一次,执行的测试也相当简单,尽管如此,做这些测试还是很麻烦的,因为每个测试都把结果输出到控制台,而又必须逐一检查它们。后来,意识到其实完全不必要盯着屏幕检查测试所得信息是否正确,大可以让计算机帮助来做。这样,就能确保所有测试都完全自动化,让它们检查自己的测试结果。

        一套测试就是一个强大的Bug侦探器,能够大大缩减查找Bug所需要的时间。当然,我们要说服别人也这么做并不是那么容易。编写测试程序,意味着要写很多额外的代码。除非你确切体验到这种方法对编程速度的提升,否则自我测试就显示不出它的意义。很多人根本没学过如何编写测试程序,甚至根本没考虑过测试,这对于编写自我测试代码也很不利。如果需要手动运行测试,那更是令人郁闷,没人愿意一直盯着屏幕看;但是如果可以自动运行,编写测试代码就真的很有趣。

        通常情况下,我们都认为测试代码应该在程序开发完成后再进行撰写。实际上,撰写测试代码的最有用的时机是在开始编程之前。每当你需要添加特性的时候,先写相应测试代码。这听起来好像离经叛道,其实不然。因为编写测试代码其实就是在问自己:添加这个功能到底要做些什么。编写测试代码还能够让你把注意力集中于接口而非实现,这永远都是好事。预先写好的测试代码也为你的工作安上一个明确的结束标志:一旦测试代码正常运行,工作就可以结束了。

        大道理听起来总是对的,尽管我相信每个人都可以从编写自我测试中受益,但这不是本文的重点。本文主要谈重构,而重构需要测试。如果你想重构,就必须编写测试代码。在JAVA中,常用的测试手法是testing main,意思是每个类都应该有一个用于测试的main()。这是一个合理的习惯,但可能不好操纵,这种做法其实很难轻松运行多个测试。比较好的做法是:建立一个独立类用于测试,并在一个框架中运行它,使测试工作更轻松。

(Ⅱ)JUnit测试框架

        本文用JUnit测试框架,这个框架非常简单,却可让你进行测试所需的所有重要事情。下面将介绍用其为一些IO类开发测试代码。
        注:(a)TestCase(测试夹具)继承了Asset类并实现了Test接口。(b)TestSuite(测试套件)实现了Test接口。

        (1)首先创建一个FileReaderTester类来测试文件读取器。任何包含测试代码的类(即测试用例)都必须继承测试框架所提供的TestCase类。其中Test是测试套件,其可以包含测试用例和其它测试套件。

public class FileReaderTester extends TestCase {
	public FileReaderTester(String method) {
		super(method);
	}
}
        (2)其次,这个新建的类需要有一个构造函数。完成后我们就可添加测试代码,首选需要设置测试夹具,即测试的对象样本。由于需要读到一个文件,所以先准备一个如下的测试文件:
Bradman   99.95  50  82  10  6789 334    29
Pollock   60.95  22  60  4   2256 334    4
Marry     80.95  56  88  4   2256 334    29
Jone      77.65  70  67  4   6789 334*   11
Sutcliffe 63.25  56  80  8   6789 331934 18

        (3)进一步运用这个文件之前,我们要准备好测试夹具。TestCase提供两个函数:setUp()用来产生相关对象,tearDown()负责删除它们现在我们有适当的测试夹具,就可以开始编写测试代码了。首先测试read(),读取一些字符,然后检查后续读取的字符是否正确。

public void testRead throws Ioexception{
	 char ch = '&';
	 for(int i = 0; i < 4; i++){
	     ch = (char)_input.read();
	  assert('d' == ch)
	}
}
        assert()扮演自动测试角色。如果assert()的参数值为true,一切良好,否则我们就会收到错误通知。下面介绍如何将测试过程运行起来:
        (1)第一步产生一个测试套件。为此设计一个suite(),如下所示:
public static Test suite() {
	TestSuite suite = new TestSuite();
	suite.addTest(new FileReaderTester("testRead"));
	suite.addTest(new FileReaderTester("testReadAndEnd"));
	return suite;
}

        这个测试套件只含有一个测试用例对象,即FileReaderTester实例。创建测试用例对象时,把待测函数的名称以字符串的形式传给构造函数,从而创建出一个对象,用以测试被指定的函数,这个测试通过JAVA反射机制和对象关联。

        (2)还需要一个独立的TestRunner类,TestRunner有两个版本,这里我们选择“文字界面”版本。对于每个运行起来的测试,JUnit都会通过良好的用户界面输出,这样你就可以直观地看到测试进展。它会告诉你整个测试花了多少时间。如果所有测试没有出错,它就会说OK,并告诉你运行了多少个测试。

public static void main(String[] args) {
	junit.textui.TestRunner.run(suite());
}
        这段代码创建出一个TestRunner,并要它运行FileReaderTester类。但我们执行时候,会看到:

        频繁地运行测试,每次编译请把测试也考虑进去——每天至少执行每个测试一次。在重构的过程中,你可以只运行少数几项测试,它们主要用来检查当下正在开发或整理的代码。是的,你可以运行少数几项测试,这样肯定比较快,否则整个测试会降低你的开发速度,使你开始犹豫是否要这样进行下去。如果测试出错,会发生什么事?为了展示我故意引进bug,使得找不到测试文件。会看到:


        这样我们就能够很快发现错误在哪里,并对代码进行修改。在编写测试代码时,我们应该先让它失败。之所以这么做是为了证明:测试机制的确可以运行,并且测试的确测试了它该测试的东西。

        下面给出上面运行的详细代码,让你能够更好地了解测试代码:

import java.io.FileReader;
import java.io.IOException;
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;

public class FileReaderTester extends TestCase {
	private FileReader _input = null;

	public FileReaderTester(String method) {
		super(method);
	}

	public static void main(String[] args) {
		junit.textui.TestRunner.run(suite());
	}

	@Override
	protected void setUp() throws Exception {
		try {
			_input = new FileReader("data.txt");
		} catch (Exception e) {
			throw new RuntimeException("不能打开测试文件");
		}
	}

	@Override
	protected void tearDown() throws Exception {
		try {
			_input.close();
		} catch (Exception e) {
			throw new RuntimeException("关闭测试文件错误");
		}
	}

	public void testRead() throws IOException {
		char ch = '&';
		for (int i = 0; i < 4; i++)
			ch = (char) _input.read();
		assertEquals('d', ch);
	}

	public static Test suite() {
		TestSuite suite = new TestSuite();
		suite.addTest(new FileReaderTester("testRead"));
		return suite;
	}

	public void testReadAndEnd() throws IOException {
		int ch = 1234;
		for (int i = 0; i < 141; i++)
			ch = _input.read();
		assertEquals(-1, ch);   //比较是否相等
	}
}

(Ⅲ)单元测试和功能测试

        JUnit框架的用途是单元测试。单元测试的目的是为了提高程序员的生产率。单元测试是高度局部化的东西,每个测试类都属于单一包。它能够测试其他包的接口,除此之外它将假设其他包一切正常。

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

       一般而言,功能测试尽可能把整个系统当作一个黑箱。面对一个拥有GUI的待测系统,它们通过GUI来操作那个系统。面对文件更新程序或数据库更新程序,功能测试只观察特定输入所导致的数据变化。

        一旦功能测试者或最终用户找到软件中的bug,要除掉它至少需要做两件事。当然必须要修改代码,才能排除错误,但你还应该添加一个单元测试,用来暴露这个bug。事实上,我们应该在收到bug报告时,首先编写一个单元测试,使bug浮现出来。


(Ⅳ)添加更多的测试

        现在我们应该添加更多的测试。我们遵循的原则是:观察类该做的所有事情,然后针对任何一项功能的任何一种可能失败情况,进行测试。记住,测试应该是一种风险驱动的行为,测试的目的是希望找出现在或未来可能出现的错误。所以我不会去测试那些仅仅读或写一个字段的访问函数,因为他们太简单了,不大可能出错。这一点也很重要,撰写过多的测试,往往测试量反而不够。测试你最担心出错的地方,这样你就能从测试工作中得到最大利益。
     (1)考虑可能出错的边界,把测试火力集中在那儿。

        测试的一项重要技巧就是“寻找边界条件”。对于read()而言,边界条件应该是第一个字符、最后一个字符、倒数第二个字符:

public void testReadBoundaries() throws IOException {
	assertEquals("read first char", 'B', _input.read());
	int ch;
	for (int i = 0; i < 222; i++)
		ch =  _input.read();
	assertEquals("read last char", 8, _input.read());

	assertEquals("read first char", -1, _input.read());

}

        你可以在断言中加一条消息。如果测试失败,这条消息就会被显示出来。

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

public void testEmptyRead() throws IOException {
	File empty = new File("empty.txt");
	FileOutputStream out = new FileOutputStream(empty);
	out.close();
	FileReader in  = new FileReader(empty);
	assertEquals(-1,in.read());
}
     (2)当事情被认为应该会出错时,别忘了检查是否抛出了预期的异常。

        测试时,别忘了检查预期的错误时候如期出现。如果你尝试在关闭流后再读取它,就应该得到一个IOException,这也应该被测试出来:

public void testReadAfterClose() throws IOException {
	_input.close();
	try {
		_input.read();
		fail("no exception for read past end");
	} catch (IOException e) {
		
	}
}
        遵循这些规则,不断丰富你的测试。对于某些比较复杂的类,可能需要花费一些时间来浏览其接口,而在这个过程中你可以真正理解这个接口。随着测试类愈来愈多,你可以生成另一个类,专门用来包含由其他测试类所组成的测试套件。
class MasterTester extends TestCase{
	
	public static void main(String[] args) {
		junit.textui.TestRunner.run(suite());
	}

	public static Test suite(){
		TestSuite suite = new TestSuite();
		suite.addTest(new TestSuite(FileReaderTester.class));
		suite.addTest(new TestSuite(FileWriterTester.class));
		//......
		return suite;
	}
}
     (3)不要因为测试无法捕捉所有bug就不写测试,因为测试的确可以捕捉到大多数bug。
        对象技术有个“微妙”之处:继承和多态会让测试变得比较困难,因为将有许多种组合需要测试。如果你有3个彼此合作的抽象类,每个抽象类有3个子类,那么你总共拥有9个可供选择的类和27种组合。并不是要试着测试所有可能组合,我们并没有那么多的时间,但是也应该尽量测试尽可能多的类,这可以大大减少各种组合所造成的风险。我们总可能遗漏些什么,但是我觉得“花一些合理的时间抓住大多数bug”要好过“穷尽一生抓所有bug”。


       本文主要介绍了自测试代码的价值、运用JUnit测试框架进行简单的测试,目的就是为了说明构建自动测试对于开发人员来说是很重要的。其实,我们缺少的不是解决问题的能力,而缺少的是很难发现问题到底出在哪儿的能力。与其花那么多的时间去寻找一个bug,还不如在开发的过程中就将其扼杀掉。本文介绍的内容还是偏向理论方面,但是不得不介绍,因为重构需要一个可靠的测试环境,即使不重构编写测试程序也很重要。

       PS:下一篇文章将正式开启重构之门:重构笔记——提炼函数。希望本文对你有所帮助。



重构笔记之前文章如下:

       重构笔记——入门篇

       重构笔记——代码的坏味道(上

       重构笔记——代码的坏味道(下)


没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试