单元测试与测试策略project.ppt

单元测试 李春雷 2007-3-9 单元测试 单元测试概念，技巧 单元测试策略 自动化测试与每日/每周构建 什么是单元测试 单元测试是指针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。 测试种类 单元测试的重要性 帮助确保产品质量。 有助于为每个class定义需求。 详尽的测试套件（test suite）是强大而重要的文档。 详尽的测试套件可让我们进行有效的回归测试。 详尽的测试套件使重构变得有保障。 使修正bug变得容易。 编写单元测试(JUnit) testcase import junit.framework.TestCase; class TestXXX extends TestCase { public void setup(){ //initialize } public void testXXX1() { //assert the result is expected. } public void tearDown() { // } } 编写单元测试(JUnit) TestSuite import junit.framework.TestSuite class ClientTestSuite extends TestSuite { public static Test suite() { TestSuite suite = new TestSuite(); suite.addTest(new TestXXX(testXXX)); //suite.addTest(new TestXXXX(... return suite; } } 单元测试为何难实施 代码太难测试 迫于项目进度要求 开发者不原意写单元测试 用“临时测试”代替“结构化的单元测试” 单元测试目标 独立进行测试 独立的测试每个类：每个测试用例只应该测试一个class。 采用降低耦合度的技术； “编写可测试的代码”的目标可以摧生出高质量的程序代码 自动化测试 提高可测试性的技巧 针对接口编程，而非针对类编程 使用Strategy模式 迪米特法则：对象只应该调用自己触手可及的对象。 确保每个对象有合理的责任集 IoC AOP Strategy pattern Strategy Pattern 参与者: Strategy：策略参与者，规定使用策略的接口（API）的参与者 ConcreteStrategy：具体策略参与者 Context：（上下文）参与者 Strategy pattern 单元测试技巧 替换对象（test stub） 可以用stub替换真正代码。目的是用一个简单一点的行为替换一个复杂的行为，从而允许独立的测试代码的一部份。 模仿对象（mock object） 用来替换与你的代码协作的对象的对象。 你的代码可以调用mock object的方法。Mocks不实现任何逻辑，它只需要满足测试类调用它时，有最底限度的应答。 编写有效测试 反向测试：测试异常情况下代码的表现 等价划分：把输入按照特征进行分类。 测试用例应当经济，同时又保持自描述性。 尽量不要依赖外部配置 必要时对测试套件进行重构。 避免编写有副作用的测试 单元测试最佳实践 观念：除了可运行的代码，测试套件比其他任何东西都重要 小步前进：反对一次性编写一大堆测试套件；应测试一点，实现一点。 首先编写独立于代码的测试 在修正某个bug前，先编写一个单元测试，来表现这个bug 即使编写依赖于J2EE API的代码，也应确保它能脱离应用服务器进行单元测试。 单元测试最佳实践 把任何代码提交到CVS前，完整的运行测试套件 测试的名字要有意义 不要依赖于测试用例的先后顺序 如果用到了配置文件，从classpath来加载。 在IDE中运行单独的测试。 编写ANT脚本来运行所有测试，以及进行测试覆盖率分析 单元测试最佳实践 使用模仿对象来避免对外部资源的依赖 在必要的时候重构测试代码。 未实现的方法，让其抛出异常。 每个测试（JUNIT测试方法）只测试一件事情。 要保证测试代码的简单性，如果测试代码本身就很复杂，就会导致测试代码本身可能也有Defect。另一方面，如果测试代码很复杂，往往说明被测试代码的设计不合理，接口不清晰，需要重新设计或是Refactory。 当前项目的测试策略 当前项目的模块性质分类 POJO对象的单元测试 项目目录结构如下： 其中：源码存放在Src目录中，对应的JUnit的testcase存放在test目录中 POJO对象的单元测试 在WSAD/