面向价值编程：低边际成本的自动化测试

1. 停止所有的开发工作，即日起全体开发投到测试库中工作。
2. 将之前的java写的测试用例全部迁到这个测试框架，如果测出bug顺便修复掉。
3. 安排一个测试同学做Gitlab CI机器人，所有patch合入都要依赖这个机器人，判断所有case跑过了才可以合入。
4. 后续版本迭代中，每一个ZStack管理平台引起的bug，合入时必须有对应的测试覆盖。
5. 安排一些测试同学来设计一些用例，并编写成测试代码。

那时笔者也参与了其中，刚开始写用例的时候，其实是十分讨厌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来增强测试用例的可读性和可维护性。