推倒重来的觉悟
最近在质量保障方面遇到一些新的挑战，对于单元测试覆盖率有了要求，所以又重新学习了一些单元测试的框架和最佳实践，例如 Spock、Mockito 以及 powermock。
在 Springboot 中实践的过程中，遇到了一些问题，大部分比较琐碎，但有一个 Mock 静态方法的场景着实让我迷茫了。
在初期调用的时候，得到的方案是mockito-inline这个框架支持的，但是后面实践中发现 Mockito 和 Spock 结合使用过程中这个方案不可行。后来转向powermock才终于找到解决办法。过程曲折，令人动容。
本着不让问题过夜的想法，终于在某一次尝试中得到了正确答案。而最终解决问题的方式就是推到重来。
在之前自学的过程中，解决问题的方案大多数来自于网络。网络上的答案是良莠不齐，一般很少能一次过的，都是需要修修补补，甚至网上的答案已经不可用，我还在这个不可用的答案上试图寻找解决之道。如果一个答案有了报错，我通常试图去通过对报错信息的追根溯源找到解决的办法。但在这个时候，我的配置和代码中已经存在了两种以上的解决方案的内容，导致使用了正确的方案，也可能不通过。
这个时候最让人心烦，看官方的文档、大牛的博客，都是 OK 的，怎么偏偏到了我手里总是exception满屏。后来我总结了一个小技巧：推倒一切，重新再来。
把所有相关的配置和代码请清空或者回复默认设置，然后寻找一个可信度较高的教程，一点点重新来过。把大的方案分解成多个小方案的集合。通过对小方案进行逐个功能验证，然后再组合成大方案的实现。
通常初学者很容易遇到这个问题，如果没有人指导，很难在短时间内找到解决之道。而初学者一旦被一个障碍点消磨了太多的精力，学习的热情和毅力就会大打折扣，对继续学习更加不利。
经过一晚上的折腾，我终于发现了为什么我之前一直失败，主要原因两个：
多个依赖之间有版本的关联，混用会导致
java.lang.NoSuchMethodError;最早的解决方案由于疏忽，没有进行更多验证，其实是错误的，一开始我一直想在这个方案微调，大部分时间都栽在这里了。
之前写过一些单元测试的文章介绍这几个框架的应用场景和实践 Demo：
欢迎关注 FunTester，Have Fun ~ Tester ！
版权声明: 本文为 InfoQ 作者【FunTester】的原创文章。
原文链接:【http://xie.infoq.cn/article/cb50b00dc4ae084acc8e7c0c7】。文章转载请联系作者。
公众号：FunTester，650+原创，欢迎关注 2020.10.20 加入
Have Fun,Tester！ 公众号FunTester，坚持原创文章的测试人。 FunTester测试框架作者，DCS_FunTester分布式性能测试框架作者。
评论