mockito

转载：http://www.blogjava.net/qileilove/archive/2014/03/07/410713.html 1.关键词 　　 单元测试 、spring、mockito 　　 2.概述 　　单元测试目前已经成为项目中保证代码质量的一种必要方法，对于一些不易构造或者不易获取的对象通过mock的方式进行测试是一种很有效的处理办法。在基于spring的mock测试中，mock对象获取和使用的便利性可以提升单元测试代码的质量。 　　 3.实现原理 　　Mock对象的注入使用注解和反射，对象注入依赖spring框架支持junit4提供的TestExcutionListeners监听器对象，在监听器中将mock对象注入到单元测试类中。 　　 4.新建对象方式代码 private IAccessServiceaccessService = Mockito.mock(IAccessService.class); @BeforeClass public static void beforeClass(){ // 构造并注入Mock对象ICmsProxyService sceneConfigService.setAccessService(accessService); } 　　 5.监听器方式代码 　　5.1 实现监听器 　

[TOC] 目标 了解 单元测试的背景 了解如何 利用 springboot 实现接口的测试 了解如何 利用 mokito 做代码的 mock 一、About 单元测试 单元测试其实是一种廉价的技术，是由开发者创建运行测试代码，用于对程序模块(软件设计的最小单位)进行正确性检验的一种做法。 而所谓的最小单元，就是指应用的最小可测试部件。 在面向对象领域，最小单元对应于类的某个成员方法。 通常意义的单元测试会用于验证某场景、某条件下某方法的行为结果，举个例子： 我想验证 Equals 方法，在两个对象类型不一致时应该返回 false 单元测试的初衷，是对各个相互独立，互不影响的基本单元基线测试，以此来保证核心代码的质量。 每一段单元测试代码，都一定会 包含几个部分 ： Arrange 用于初始化一些被测试方法需要的参数或依赖的对象。 Act方法 用于调用被测方法进行测试。 Assert 用于验证测试方法是否按期望执行或者结果是否符合期望值 See ！并不是很复杂，可是大多数开发者并不喜欢做单元测试。 而且，有一个现象很有意思，水平越高的程序员，越不喜欢写测试代码，why? “ 因为单元测试，主要是用来防低级程序员挖坑的啊 ” 这句话不是我说的，但却代表了相当一部分程序员的心声.. 那么，单元测试到底要不要做，并不是本文要讨论的问题。 建议大家阅读下 《单元测试之道-Java版本》

原文见 此处 单元测试是编写测试代码，用来检测特定的、明确的、细颗粒的功能。单元测试并不一定保证程序功能是正确的，更不保证整体业务是准备的。 单元测试不仅仅用来保证当前代码的正确性，更重要的是用来保证代码 修复 、 改进 或 重构 之后的正确性。 一般来说，单元测试任务包括 接口功能测试：用来保证接口功能的正确性。 局部数据结构测试（不常用）：用来保证接口中的数据结构是正确的 比如变量有无初始值 变量是否溢出 边界条件测试 变量没有赋值 （即为NULL） 变量是数值（或字符) 主要边界 ：最小值，最大值，无穷大（对于DOUBLE等） 溢出边界 （期望异常或拒绝服务）：最小值-1，最大值+1 临近边界 ：最小值+1，最大值-1 变量是字符串 引用“字符变量”的边界 空字符串 对字符串长度应用“数值变量”的边界 变量是集合 空集合 对集合的大小应用“数值变量”的边界 调整次序 ：升序、降序 变量有规律 比如对于Math.sqrt，给出n^2-1，和n^2+1的边界 所有独立执行通路测试：保证每一条代码，每个分支都经过测试 代码覆盖率 语句覆盖 ：保证每一个语句都执行到了 判定覆盖（分支覆盖）：保证每一个分支都执行到 条件覆盖：保证每一个条件都覆盖到true和false（即if、while中的条件语句） 路径覆盖：保证每一个路径都覆盖到 相关软件 Cobertura：语句覆盖 Emma:

小王是个积极进取的程序员， 在日常工作之余，他还学习单元测试，重构等编程实践。 突然有一天晚上他看到微信群里在激烈地争论一个叫TDD的东西，不由地来了兴致，上网搜索了一下。 原来TDD就是Test Driven Development(测试驱动开发)，强调测试先行，小步快跑，用测试用例驱动出程序的接口和代码。 1 TDD步骤看起来异常简单： 1. 写一个失败的测试用例 2. 写一点代码，让这个测试通过 3. 重构代码（如果需要的话），转到第一步 小王心想，这三个步骤不就是“ 把大象关到冰箱里 ”嘛，太抽象了! 一点儿都不实用！ 他又搜了一些文章，发现这些文章中讲的都是一些极其简单的例子，如加减法计算器，货币转换等等。 比如这个计算器的例子，第一步先写一个简单的测试用例，用来测试两个数字相加的行为。 public class CalculatorTest { @Test public void testAdd(){ Calculator calculator = new Calculator(); int result = calculator.add(10,20); Assert.assertEquals(30, result); } } 第二步在Calculator中实现add方法，完成两个数相加的逻辑，让测试通过。 public class Calculator{ public

【推荐阅读】微服务还能火多久？>>> 现在大公司越来越重视项目的单元测试，甚至明确要求项目的单元测试覆盖率不能低于某个值，足可见单元测试的重要性； 试想如果没有单元测试，那么如何保证代码能够正常运行呢？ 测试人员做的只是业务上的集成测试，也就是黑盒测试，对单个的方法是没有办法测试的，而且，测试出的 bug 的范围也会很广，根本不能确定 bug 的范围，还得去花时间来确定 bug 出在什么地方。 另外，一个最常见的问题：写单测浪费时间？ 你有没有计算过你改bug的时间（定位+修复），算一下的话你会发现时间浪费的会更多。 参考建议 关于如何写好单元测试，下面有几条建议供大家参考： 1. 测试数据外部化 测试数据大致分为两种：变化的和不变化的，对于不变的测试数据，我们完全可以写在单元测试用例代码中，也可以将数据外部化。 而对于测试数据一直在变，并且测试数据量比较大的时候可以使用测试数据外部化将数据放在测试用例的外部进行统一管理。 什么是数据外部化 ？就是将数据放在单元测试用例的外部统一管理，比如我们可以将一个单元测试用例中的测试数据统一放在一个CSV文件中。 我们就可以通过比如junit5中的参数测试注解 @ParameterizedTest 和引入CVS文件的注解 @CsvFileSource 并指定其中的resources属性指定CSV文件，numLinesToSkip = n