第17章讲、测试报告和通过准则(理论课).ppt

4/39 一个类可能被其他的应用程序所使用，这个类的单元测试也应当能够在其他的应用环境中正常运行。因此，为一个类编写单元测试应当尽量避免使用被测试类没有使用的其他类。如果被测试的类没有使用而单元测试使用了另外一个类，在该类和它的单元测试移到其他应用程序时，会把很多不必要的类连带过去。造成不必要的重用开销和维护成本。 频繁地测试一个类的非接口方法是一种不正常的信号。测试代码是一种客户代码，它代表将来其他客户代码使用被测试类的方式。对非接口方法的测试意味着测试依赖于类的实现而非类的接口，也就是说，即使类的接口不变，它实现的变化会造成测试的变化。要解决这个问题的方法有两个。最直接的方法一种就是把这些非接口方法接口化。另外一种方法需要我们了解这些非接口方法测试的来源。通常，接口方法是一系列非接口方法的表现。相对而言，它们的粒度更大。产生非接口测试很重要一个原因是某些行为的实现非常复杂，无法一步用代码完成这样的测试，而是需要一步一步增量“跟踪”，最后实现一个“大的”测试。不会令人惊奇，由于这种行为具有的复杂性，通常意味着需要为这些方法和状态建立独立的类。这时可能最需要是进行重构。要记住的一件事情就是，一个对象的接口是稳定的，它封装了实现，而实现是相对可变的。所以：测试要依赖接口，不要依赖实现。 很多时候，对一个类的单元测试需要涉及到被测试单元的很多成员函数.这些函数必须以固定的顺序被执行。譬如说，必须先做func1，接着是func2，接着又是func3。出现这样的现象表明，为了执行一个单独的任务，需要组合几个方法，每一个后续方法使用前面方法的聚集效果。如果一个类中很多方法必须组合才能完成一个单一的任务,那么这个类就会变得更加复杂，更加难以使用，因为无法强制客户代码按照编码实现人员打算的数据和方法组合来完成这样的一个任务。应当对被测试的类进行refactoring，使用composed method为该类提供一个组合方法，这个方法可以更容易被用户理解(因为它有独立的意图和任务)、使用，并且不容易出错。 31/39 不符合编码标准的错误 一行中声明了多种类型变量 从一个抽象类库中的构造器调用的抽象方法 包含大量case语句的switch语句 有一个以上的main（）函数 直接弹出的Exception类库 catch语句中的Exception或者RuntimeException 直接弹出的Error没有在接口中定义的变量 长整数应该使用“L”代替小写字母“l” 命名惯例等不符合标准 32/39 逻辑错误 条件表达式 循环表达式 switch语句 33/39 条件表达式 先看下面代码： if((a1a=10)(a10a20)) { //执行正常业务处理 } else { //执行异常业务处理 } 34/39 多线程错误 访问和修改共享资源 public void Func1(){ lockDatabase(db); lockFile(file); releaseLock(db); releaseLock(file); } public void Func2(){ lockFile(file); lockDatabase(db); releaseLock(file); releaseLock(db); } 35/39 读取数据错误 先看下面代码： public class ReadConfigureFile{ public static void main(String[] arge){ File file=new File(Configure.txt); FileReader reader=new FileReader(file); System.out.println(input.read()); } } 36/39 读取数据错误（续） 先看下面代码： public class ReadConfigureFile{ public static void main(String[] arge){ try{ File file=new File(Configure.txt); FileReader reader=new FileReader(file); System.out.println(input.read()); } catch(FileNotFoundException f){ System.out.println(File Not Found); }catch(Exception e){ System.out.println(e.getMessage()); } } } 37/39 集成错误 先看下面代码