单元测试ppt

 

单元测试ppt思路详解

目前的情况：
1，如今不少单元测试只是利用@Test注解把代码或者整个请求接口内的business作测试
2，单测的过程就不少查数据库的方法，可是不必每次都测sql，由于sql测一遍都应该是正确的。
3，单测代码启动速度、效率过低
4，没有在各个环境整个工程单元测试经过
5，未采用assert机制，采用system.out.println进行人工核查输出状况
6，关闭了jenkins上单元测试流程
7，时间紧，开发经过swagger页面和端点调试进行代码功能的验证工做





目标改进：
1，单元测试启动效率提高
2，脱离环境，在每一个环境都放心执行
3，提供代码覆盖率
4，用于改善和提升开发效率、编码质量、编码可读性、减小冗长的代码行
测试金字塔：

​​​​​​

AIR 原则：

Automatic(自动化)：单元测试应该是全自动执行的，而且非交互式的。

Independent(独立性)：保持单元测试的独立性。为了保证单元测试稳定可靠且便于维护

Repeatable(可重复)：单元测试是能够重复执行的，不能受到外界环境的影响。

​
老板为我有效的代码支付薪酬，而不是测试，因此个人理念是在能达到的自信水平上作越少的测试越好（我以为这种自信水平应该要高于行业内的标准，固然这也可能只是个人自大）。我对编码过程当中一般都不会犯的一类错误（好比在构造方法中错误地赋值）不会进行测试，而更倾向于对那些有意义的错误进行测试，因此对于一些具备业务逻辑的复杂条件我会特别当心。当在一个团队中合做时，我会很是当心地修改个人策略，以便测试那些容易让团队出现错误的地方。

如何作：
1，必须基于团队正式的代码工程，而不是随便找一个示例代码工程来说解——这样的书和文章已经太多了，我不会比他们作的更好；

2，必须识别并提取出小的可测试单元，但不要让团队成员学习更多的高深的知识，好比设计模式、Mock&Stub等；

3，最好可以度量，好比能提升10% - 20% 的测试覆盖率。

单元测试的编写，主要包含如下几个阶段：

1. 数据准备：在编写测试用例前，须要依赖到一些数据，数据来源通常是数据库。

2. 构造参数及打桩（stub）：调用方法须要传递入参，依赖的类须要作mock和stub

3. 执行测试：这一步比较简单，直接调用被测方法便可。

4. 结果验证：这里除了验证被测方法的返回值外，还须要验证插入到数据库中的数据是否正确，某外部方法被调用过n次或未调用过。

5. 必要的清理：对打桩进行清理，对数据库脏数据进行清理。
   
   
   

mockio使用基础，主要是两个注解的认识，而后其它语法请本身参照

@mock  Mock声明的对象，对函数的调用均执行mock（即虚假函数），不执行真正部分。
@spy Spy声明的对象，对函数的调用均执行真正部分。
@InjectMocks 通常来修饰你须要测试的顶层类。使用这个注解能够建立一个实例，而且将你用@Mock注解的对象注入到这个实例中。

@spy +@Autowired 这个对象的依赖的类也是会自动autowired，若是个人依赖的对象还有依赖（这在大多数的项目中是很是常见的），根据上面的说法用@Spy的对象是不会自动注入依赖的
@InjectMocks+@Autowired  两个注解叠加使用，让@Autowired注解为对象注入真依赖。

when和doReturn

when(dao.getOrder()).thenReturn("returened by mock ");

doReturn(expected).when(underTest).methodToTest();

使用when去设置模拟返回值时，它里面的方法（dao.getOrder()）会先执行一次。

使用doReturn去设置的话，就不会产生上面的问题，由于有when来进行控制要模拟的方法，因此不会执行原来的方法。

分层的测试：
给一个目前的图例：controller-》service-》dao层的测试
​


提供mybatis层，service层，controller的测试

数据库有dbunit，spring 的@sql注解来实现数据载入

service层的测试：


controller层的测试如何测。

@RunWith(SpringRunner.class) : SpringRunner是SpringJUnit4ClassRunner的简写，它扩展了BlockJUnit4ClassRunner类，用于提供测试时的Spring应用上下文信息。
@WebMvcTest(value=UserController.class,secure = false) : 该注解用于测试Spring MVC应用程序，使用此注解的好处是咱们只须要加载UserController类并对其中的方法进行单元测试，而不须要加载其余的控制器。
@MockBean : MockBean主要是模拟向Spring应用上下文注入一个Bean对象，并使该Bean对象能够在控制器中被访问到。
MockMvc : MockMvc是测试Spring MVC应用程序的主要入口，它将为咱们的测试提供一个模拟的应用上下文环境。

普通的按照service的测试模式能够吗?丢失了什么东西：
须要springmockmvc来测试：
mockcontroller层依赖的service和utils类的方法

如何measuser测试覆盖率：
IDEA如何测试代码的覆盖率统计

一些tips：
1，若是写了一些实际调用其它系统的单元测试，可是在跑jenkins单元测试依赖环境不能部署怎么办。添加igonore注解
2，@PrepareForTest(HelloUtil.class)
一些问题：
1，在开启单元测试后，每次部署慢的状况如何解决（目前只包含打包，上传和部署都有7分钟的gap时间了，如何改进）
2，要作好单元测试，首要条件是要有单元。若是组件内的代码没有分红清晰独立的小单元，那单元测试就无从谈起。因此，三分测试，七分设计。
若是能将代码合理地拆分红不一样的单元，你就会发现，大部分单元，如图中绿色部分所示，都是很是独立的，它们不依赖数据库等外部资源，只是一个内存的计算，因此这部分是很是容易作自动化单元测试的。
因此，当你的应用的自动化单测覆盖率只是个位数的话，先不要急着引入MOCK框架这类工具，当务之急是作这种单元化的改造，测试那些投入产出效果明显的部分。之后在用MOCK等方式测试其它的部分。

在介绍这些单元测试的方法后，你们能不能总结一下单元测试应该具体什么特性：

• 有效：只测试 核心的业务逻辑
• 单元：核心的每一个小方法的测试
• 覆盖场景：除了测试正常流程，还要测异常流程，
• 可重复执行：不依赖db和redis的外部依赖，采用h2数据库
• 断言：

时间比较紧，是否能够采用代码生成的方式来生成测试代码