单元测试讲义.ppt

单元测试 快速的编程反馈 软件开发的困难 软件总是要修改的 添加新特性 Fix bug 优化 重构 软件开发的困难 修改软件是危险的举动 我们如何得知已经正确的完成了修改？ 我们如何得知没有破坏任何（既有的）东西？ 软件开发的困难 当前我们如何测试修改 编译 启动服务器 启动一个以上的客户端 鼠标操作 看看效果 重复这些步骤 软件开发的困难 这种测试的缺点 不能立即获得反馈 时间漫长 运行次数不足 甚至不测试 软件开发的困难 这种测试的外号 编辑并祈祷 单元测试 概念 由一组独立的测试构成，其中每个测试针对软件中的一个单独的原子行为单元 并非检查一簇类是否能够合作良好，而是检查单个的对象行为是否正确 单元测试 传说中的例子，被测试的对象非常独立 单元测试 传说中的过程 实例化被测试对象 提供测试数据 调用被测试的方法 验证测试结果 单元测试 实际情况1 内存访问异常，ItemMngS无法在测试中实例化 单元测试 实际情况2 内存访问异常，无法调用被测试的方法 单元测试 实际情况3 函数没有返回值，不知道如何验证结果 单元测试 实际的情况 理想是美好的，世界是残酷的 软件由对象的相互协作来实现功能，对象之间充斥着必不可少的依赖 软件的运行依赖于数据库，网络和文件系统 多数函数的并没有返回值来验证行为 单元测试 比如 CServerCha依赖各种CXXMng CXXMng之间相互依赖 Auto_PlayerData是数据库的接口 单元测试 依赖的坏处 无法将某个类从软件中隔离出来 无法轻易的安置单元测试 单元测试 不经意的转变成集成测试 我们可以将被依赖的类在测试中实例化 被依赖的类肯定也在依赖别的类 一环扣一环，于是我们把整个软件的大部分类都牵扯到一次测试中 这个单元测试变得笨重 这已经不是单元测试了！！！ 解依赖 有依赖，就要解依赖 在被测试的代码中，依赖是少量的 解依赖就是将无法放入测试中的小段代码从整块代码中分离出来的行为 解依赖就是构造接缝的过程 解依赖 什么是接缝？ 接缝是指程序中的一些特殊的点，在这些点上你无需作任何修改就可以达到改动程序的目的 如果能够将接缝处的行为取代掉，我们就等于有选择的排除了某些依赖 我们还可以将被依赖方替换为其他代码，以此感知测试代码对被依赖方的要求和影响 解依赖 其实接缝就是间接层 接缝的基本类型 虚函数 指针：函数指针，全局变量，参数 解依赖 虚函数 虚函数是接缝的根本 在不改变软件的前提下，虚函数的行为可以在测试中的被派生类所改变 解依赖 code 解依赖 伪对象 由于虚函数的存在，在测试中的派生类可以改变原来的行为 在测试中用于伪装成被测试类的合作者的对象，称为伪对象 伪对象是后面介绍的解依赖技术的根本 解依赖 全局变量 实例化的全局对象是恶劣的，如：CPlayerMng g_playerMng; 隐性初始化的单件是恶劣的，如：CCommonTimerMng::Instance(); 对象指针是一个接缝，可以在测试中替换指针实际指向的对象 改变对象的行为需要虚函数 解依赖 code 解依赖 函数指针 全局函数是不可替换的，如：G_GetPlayerUnit 但是函数指针可以在测试中替换为其他签名相同的函数 解依赖 code 解依赖 参数指针 参数对象指针和全局对象指针一样，可以在测试中替换实际指向的对象 行为的改变依赖于虚函数 解依赖 code 解依赖 完全没有找到接缝，怎么办？ 没有接缝就创造接缝 解依赖 创建接缝的方法 提取并重写调用 设置并替换 提取并重写获取方法 提取并重写工厂方法 解依赖 提取并重写调用 被测试的代码中，委托了其他的对象做某件事情 给被测试对象新添加一个虚函数，封装这个委托 在测试中用派生类覆盖这个虚函数 解依赖 code 解依赖 设置并替换 对被依赖的对象或者单件提供一个设置方法 在测试中，用设置方法改变他们 解依赖 code 解依赖 提取并重写获取方法 在被测试的代码中，委托了其他对象做某件事情 给被测试类添加一个获取委托对象的虚函数 在测试中用派生类覆盖这个虚函数 解依赖 code 解依赖 提取并重写工厂方法 构造函数包含太多依赖，以至于无法实例化被测试的类 将依赖的代码提取到一个虚函数中 在测试中覆盖该虚函数 解依赖 code 解依赖 创建接缝的更高级的方法 参数包装器 方法对象 解依赖 参数包装器 有些类是无法修改的，final的 有些类几乎无法实例化，解依赖也很费劲 对这样的类，总是可以用wrapper将它包起来 将实际代码中对该类的依赖换为对wrapper的依赖 Wrapper有一套抽象的接口 解依赖 code 解依赖 方法对象 有一些类十分巨大 被测试的方法又臭又长 创建一个新类，该类只有一个方法 将被测试的