Junit单元测试驱动开发.ppt

测试驱动开发 目录 测试驱动开发简介 为什么会出现测试驱动开发 这段代码究竟想表达什么意思？ 奇怪了，怎么代码跟开发文档上有这么大的差别啊？ 代码现在越来越乱了，我都不敢修改代码了，修改了这个地方，天晓得会引起多少别的地方出错啊! 这个地方的代码怎么好象在那个地方看到过啊？这个程序里怎么会有这么多的重复代码呢？ 开发人员 他们到底在搞什么啊，有没有从用户的角度考虑啊，我新增一个票据订单，订单项竟然可以输入负数。 ！！！！！！ 。。。。。 为什么会出现测试驱动开发 测试人员 这下好了，让他们修改了一个BUG，现在一下子来了这么多的BUG 项目部在干什么啊，BUG怎么这么多，他们有没有自己先测试一下啊 什么是测试驱动 测试驱动想达到的目标 目录 测试驱动开发入门 如何开始 原则一:测试隔离 ?不同代码的测试应该相互隔离。 ?对一块代码的测试只考虑此代码的测试，不要考虑其实现细节 原则二：一顶帽子 ?做不同的事，承担不同的角色。 ?注意力集中在当前工作上，不要过多考虑其他方面的细节，保证头上只有一顶帽子 原则三：测试列表 ?需要测试的功能点很多 ?在任何阶段想添加功能需求问题时，把相关功能点加到测试列表中，再继续手头工作 原则四：先写断言 ?编写对功能代码的判断用的断言语句，然后编写相应的辅助语句 原则五：可测试性 ?遵循比较好的设计原则的代码都具备较好的测试性。比如比较高的内聚性，尽量依赖于接口等 原则六：及时重构 ?无论是功能代码还是测试代码，对结构不合理，重复的代码等情况，在测试通过后，及时进行重构 原则七：小步前进 ?把所有的规模大、复杂性高的工作，分解成小的任务来完成 ?每个功能的完成就走测试代码－功能代码－测试－重构的循环 范围、粒度 对哪些功能进行测试？ 会不会太繁琐？ 什么时候可以停止测试？ 对那些你认为应该测试的代码进行测试 什么时候写 如何编写用例 操作过程尽量模拟正常使用的过程 全面的测试用例应该尽量做到分支覆盖，核心代码尽量做到路径覆盖 测试数据尽量包括：真实数据、边界数据 测试语句和测试数据应该尽量简单，容易理解 为了避免对其他代码过多的依赖，可以实现简单的桩函数或桩类（Mock Object） 如果内部状态非常复杂或者应该判断流程而不是状态，可以通过记录日志字符串的方式进行验证 如何编写用例 在开发一个新的功能之前: OK,我们知道这个method中的这段代码要做什么，而且这段代码也足够简单。 如何编写用例 如何编写用例 如何编写用例 JUnit介绍 JUnit介绍 目录 测试与重构 什么是重构 重构的好处 重构的时机 存在重复的时候 觉察到代码所表达的意图不明确的时候 代码有味道的时候 重构与测试的关系 大话西游之单元测试[转载] “我知道这个项目bug很多，无法按时完成，即使老板把我炒了也是应该的。曾经有一个做单元测试的机会放在我面前，我没有珍惜，等到后来项目雪崩了才后悔。如果上天能给我再来一次机会的话，我会对老板说：我要做单元测试！如果一定要在单元测试上加个日期，我希望是一直。” 可怜的老兄，我早该告诉他应该先测试，再编码！ 结束语 谢谢您的聆听！ 敢于担当 兑现承诺 我的代码 我 负 责