Junit单元测试驱动开发汇编.ppt

JUnit介绍 然后为这个功能（Method）写单元测试例子 Unit Test 单元测试例子要覆盖这个Method的 “做什么”。 所以我们至少有了两个测试例子: Test Case 1: 测试成功增加一个用户 Test Case 2: 测试增加一个已存在的用户 其他边缘情况测试： Test Case 3: 传入的Account对象为NULL 目录 测试与重构 什么是重构 重构的好处 重构的时机 存在重复的时候 觉察到代码所表达的意图不明确的时候 代码有味道的时候 目录提纲 测试驱动开发 目录 测试驱动开发简介 测试驱动开发入门 测试与重构 测试驱动开发简介 Why 为什么会出现测试驱动开发 What 什么是测试驱动 How 测试驱动所要达到的目标 为什么会出现测试驱动开发 这段代码究竟想表达什么意思？ 奇怪了，怎么代码跟开发文档上有这么大的差别啊？ 代码现在越来越乱了，我都不敢修改代码了，修改了这个地方，天晓得会引起多少别的地方出错啊! 这个地方的代码怎么好象在那个地方看到过啊？这个程序里怎么会有这么多的重复代码呢？ 开发人员 他们到底在搞什么啊，有没有从用户的角度考虑啊，我新增一个票据订单，订单项竟然可以输入负数。 ！！！！！！ 。。。。。 为什么会出现测试驱动开发 测试人员 这下好了，让他们修改了一个BUG，现在一下子来了这么多的BUG 项目部在干什么啊，BUG怎么这么多，他们有没有自己先测试一下啊 什么是测试驱动 QA 项目部在干什么啊，BUG怎么这么多，他们有没有自己先测试一下啊 这下好了，让他们修改了一个BUG，现在一下子来了这么多的BUG 他们到底在搞什么啊，有没有从用户的角度考虑啊，我新增一个票据订单，订单项竟然可以输入负数。 测试驱动想达到的目标 测试驱动是一种开发形式 首先要编写测试代码 除非存在相关测试，否则不编写任何产品代码 由测试来决定需要编写什么样的代码 要求维护一套详尽的测试集 clean code that work 目录 测试失败时，才写代码 消除重复设计，优化设计结构 代码整洁可用 测试驱动开发入门 测试驱动开发简介 测试驱动开发入门 测试与重构 如何开始 如何开始 原则 测试技术 原则一:测试隔离 ?不同代码的测试应该相互隔离。 ?对一块代码的测试只考虑此代码的测试，不要考虑其实现细节 原则二：一顶帽子 ?做不同的事，承担不同的角色。 ?注意力集中在当前工作上，不要过多考虑其他方面的细节，保证头上只有一顶帽子 原则三：测试列表 ?需要测试的功能点很多 ?在任何阶段想添加功能需求问题时，把相关功能点加到测试列表中，再继续手头工作 原则四：先写断言 ?编写对功能代码的判断用的断言语句，然后编写相应的辅助语句 原则五：可测试性 ?遵循比较好的设计原则的代码都具备较好的测试性。比如比较高的内聚性，尽量依赖于接口等 原则六：及时重构 ?无论是功能代码还是测试代码，对结构不合理，重复的代码等情况，在测试通过后，及时进行重构 原则七：小步前进 ?把所有的规模大、复杂性高的工作，分解成小的任务来完成 ?每个功能的完成就走测试代码－功能代码－测试－重构的循环 范围、粒度 对哪些功能进行测试？ 会不会太繁琐？ 什么时候可以停止测试？ 对那些你认为应该测试的代码进行测试 大师Kent Benk? 什么时候写 明确当前要完成的功能。可以记录成一个 TODO 列表 快速完成针对此功能的测试用例编写 测试代码编译不通过 编写对应的功能代码 测试通过 对代码进行重构，并保证测试通过 如何编写用例 操作过程尽量模拟正常使用的过程 全面的测试用例应该尽量做到分支覆盖，核心代码尽量做到路径覆盖 测试数据尽量包括：真实数据、边界数据 测试语句和测试数据应该尽量简单，容易理解 为了避免对其他代码过多的依赖，可以实现简单的桩函数或桩类（Mock Object） 如果内部状态非常复杂或者应该判断流程而不是状态，可以通过记录日志字符串的方式进行验证 如何编写用例 在开发一个新的功能之前: OK,我们知道这个method中的这段代码要做什么，而且这段代码也足够简单。 测试隔离 不同代码的测试应该相互隔离。 对一块代码的测试只考虑此代码的测试，不要考虑其实现细节 一顶帽子 做不同的事，承担不同的角色。 注意力集中在当前对应工作上，而不要过多的考虑其他方面的细节，保证头上只有一顶帽子 测试列表 需要测试的功能点很多 在任何阶段想添加功能需求问题时，把相关功能点加到测试列表中，然后继续手头工作 先写断言 编写对功能代码的判断用的断言语句，然后编写相应的辅助语句 可测试性 遵循比较好的设计原则的代码都具备较好的测试性。比如比较高的内聚性，尽量依赖于接口等 及时重构 无论是功能代码还是测试代码，对结构不合理，重