| 版本 | 日期 | 备注 |
|---|---|---|
| 1.0 | 2022.11.14 | 文章首发 |
本文首发于泊浮目的掘金:https://juejin.cn/user/1468603264665335
0. 前言
17年刚加入ZStack时，ZStack正在经历从能用到好用的阶段。这个阶段会有更多的需求，对质量的要求也会更高。举个例子，toB的产品如果在一个行业里拓展开，一般都会想办法拿下龙头企业。大家都是这么想的，你会面临更多的竞争对手。抛去其他层面，单从技术层面来说，技术人员不仅需要提供相应的功能满足客户需求，还需要考虑功能在不同的场景下还能够良好的运作。
1. 前兆
周一日常周会，当研发们汇报完自己的工作后。PM开始清点当前版本遗留的bug，这时张鑫发现bug比往常多了点，测试的负责人也开始说起了近期问题的增长。这让张鑫十分的苦恼，那时的我却没意识到什么。
直到过了几年我开始带团队了我才意识到这是一种前兆——系统的复杂度正在失控，这种失控在后续的迭代中会带来越来越多的问题。
后面研发与测试单独拉了一个小会，讨论了一下目前的具体问题与细节。有人谈到了自动化测试——目前的自动化测试实在太难用了，java的代码，xml的数据配置：虽然数据和行为解耦，但写起来只觉得啰嗦，并没有觉得多方便，大家都不太乐意去写。这个会开完不久后，张鑫神速的撸出了一个测试框架。
这个框架具体的实现以及一些实用tips在本文中不会再介绍，这个在ZStack的Github Repo wiki里有介绍，我之前的文章也做过相关分析，有兴趣的读者可以自行翻阅。
2. Bug大整治
测试框架出世之后，所有开发又被拉到了一个会议室。张鑫介绍了一下自己的测试框架以及使用方法，并开始分配之后的工作：
- 停止所有的开发工作，即日起全体开发投到测试库中工作。
- 将之前的java写的测试用例全部迁到这个测试框架，如果测出bug顺便修复掉。
- 安排一个测试同学做Gitlab CI机器人，所有patch合入都要依赖这个机器人，判断所有case跑过了才可以合入。
- 后续版本迭代中，每一个ZStack管理平台引起的bug，合入时必须有对应的测试覆盖。
- 安排一些测试同学来设计一些用例，并编写成测试代码。
那时笔者也参与了其中，刚开始写用例的时候，其实是十分讨厌groovy的——动态类型的语言对开发者的要求相对来说高了一点，作为groovy新手是有点麻烦的——很多问题直到runtime才会报错。但groovy又是强类型的，因此在runtime时不会跑出很奇怪的结果（JS就会），只会报错。提供了一定方便性的同时，也没增加多少debug成本。
强弱类型：强类型意味着确认了类型以后，如果强转一个错误类型时，将会报错（编译期or runtime）；而弱类型则允许强转，这种情况下则可能产生一些令人意想不到的事。
动态VS静态类型：静态类型需要在编译器就确定字段的类型；而动态类型则会在runtime时根据上下问推导类型——因此我们可以在不知道方法具体细节的情况下编写对象上的调用语句。在运行期间，对象会动态地响应方法或消息。
在后来阅读测试框架实现时，笔者逐渐发现了动态类型的魅力——尤其是在测试场景，可以轻松的mock相关方法的返回值，来形成针对性的case。
这部分主要体现在groovy对于元编程的支持上。
同时，groovy还有一些语法糖并支持操作符重载——这意味着可以轻松的创建DSL。这让测试代码写起来非常的舒服，完全没有了之前写java时的verbose。
3. 小结
当测试框架完全落地后，我们开始了新一轮的迭代。这次迭代过程中，经QA统计，bug趋于收敛，这意味着测试框架产生了价值：
- bug通过case one by one覆盖，节省了测试在回归上的人力消耗。
- 从全局来看，避免了测试环节报bug的反复沟通与测试，优化了业务的吞吐量。
回头看，这个测试框架做的事用Junit+Mockito也可以做到。但一个好的测试框架，还会带来更低的边际成本——每个开发能够快速的编写测试代码，而由于测试框架本身提供的DSL与groovy的特性，让代码量相比原版java的test case有效减少，从而有了更强的可维护性。
有关好的测试框架，在之后文章还会讨论——比如Spock通过语义标签以及DSL来增强测试用例的可读性和可维护性。
