单元测试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数据库
• 断言：

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