推倒重来的觉悟

最近在质量保障方面遇到一些新的挑战，对于单元测试覆盖率有了要求，所以又重新学习了一些单元测试的框架和最佳实践，例如Spock、Mockito以及powermock。

在Springboot中实践的过程中，遇到了一些问题，大部分比较琐碎，但有一个Mock静态方法的场景着实让我迷茫了。

在初期调用的时候，得到的方案是mockito-inline这个框架支持的，但是后面实践中发现Mockito和Spock结合使用过程中这个方案不可行。后来转向powermock才终于找到解决办法。过程曲折，令人动容。

本着不让问题过夜的想法，终于在某一次尝试中得到了正确答案。而最终解决问题的方式就是推到重来。

在之前自学的过程中，解决问题的方案大多数来自于网络。网络上的答案是良莠不齐，一般很少能一次过的，都是需要修修补补，甚至网上的答案已经不可用，我还在这个不可用的答案上试图寻找解决之道。如果一个答案有了报错，我通常试图去通过对报错信息的追根溯源找到解决的办法。但在这个时候，我的配置和代码中已经存在了两种以上的解决方案的内容，导致使用了正确的方案，也可能不通过。

这个时候最让人心烦，看官方的文档、大牛的博客，都是OK的，怎么偏偏到了我手里总是exception满屏。后来我总结了一个小技巧：推倒一切，重新再来。

把所有相关的配置和代码请清空或者回复默认设置，然后寻找一个可信度较高的教程，一点点重新来过。把大的方案分解成多个小方案的集合。通过对小方案进行逐个功能验证，然后再组合成大方案的实现。

通常初学者很容易遇到这个问题，如果没有人指导，很难在短时间内找到解决之道。而初学者一旦被一个障碍点消磨了太多的精力，学习的热情和毅力就会大打折扣，对继续学习更加不利。

经过一晚上的折腾，我终于发现了为什么我之前一直失败，主要原因两个：

1. 多个依赖之间有版本的关联，混用会导致java.lang.NoSuchMethodError;
2. 最早的解决方案由于疏忽，没有进行更多验证，其实是错误的，一开始我一直想在这个方案微调，大部分时间都栽在这里了。

之前写过一些单元测试的文章介绍这几个框架的应用场景和实践Demo：

• Maven和Gradle中配置单元测试框架Spock
• Groovy单元测试框架spock基础功能Demo
• Groovy单元测试框架spock数据驱动Demo
• 人生苦短？试试Groovy进行单元测试
• 模糊断言
• 使用WireMock进行更好的集成测试
• 如何测试这个方法--功能篇
• 如何测试这个方法--性能篇
• 单元测试用例
• 关于测试覆盖率
• JUnit 5和Selenium基础（一）
• JUnit 5和Selenium基础（二）
• JUnit 5和Selenium基础（三）
• Spock 2.0 M1版本初探
• Mock System.in和检查System.out
• 单元测试框架spock和Mockito应用
• Mockito框架Mock Void方法

欢迎关注FunTester，Have Fun ~ Tester ！

• 140道面试题目（UI、Linux、MySQL、API、安全）
• 分享11份笔试题
• 分享一份Fiddler学习包
• 微软Zune闰年BUG分析
• 绑定手机号性能测试
• 自动化测试生命周期
• 软件测试中质量优于数量
• Web安全检查
• 基于代码的自动化和无代码自动化
• Python版Socket.IO接口测试脚本
• 线程池处理批量接口请求实践
• Golang fasthttp实践
• 控制台彩色输出
• Automa基础功能演示