Go语言单测方案之辩

提出问题

很多公司会要求代码的单测覆盖率,在编写单测时难免会遇到一些问题,想象一个场景

Go 复制代码
func A(){
    aInt := 1
    aStr := "a"
    idx, err := B(aInt, aStr)
    if err!= nil {
        return C(idx)
    }
    return err
}

func B(){
    X()
    Y()
}

当我对func A进行测试时,我并不关注func B内部的实现细节,涉及远程调用,数据库连接等原因,我也并不希望func B真的调用其他服务。

因此我希望使用一个"假函数", 规定好他的输入与输出。那么如何实现这个功能呢?一般情况下会有两种思路:

  • 以monkey为主流的直接对函数进行Mock
  • 依赖倒置

实际上也会有其他方法,但是并非主流,此处不赘述。

Mock与依赖倒置的比较

gomonkey

monkey本身在开源协议上有些局限,作者虽然公开了代码,但并不允许任何商用:

Copyright Bouke van der Bijl. I do not give anyone permissions to use this tool for any purpose. Don't use it. I'm not interested in changing this license. Please don't ask.

所以我们这里主要聚焦在gomonkey

gomonkey的实现方式很简单,

Golang 复制代码
gomonkey.ApplyMethod(type, func_name, mock_func)

在使用上极度简单的同时,也隐藏着一些隐患,gomonkey实现的原理是在代码运行时直接替代待调用函数的指针地址。这本质上是不安全的,所以出现了以下问题:

  • 苹果觉得不安全,所以在M1芯片上不允许使用gomonkey,导致大多数互联网员工不能随意使用gomonkey
  • 直接修改指针地址本身并不并发安全,因此一旦并发mock,可能就会出现未知的问题。
  • 当前gomonkey的底层实现依赖go语言底层ABI(application binary interface),Go只保证在API上的向下兼容,但并不保证ABI(比如曾经基于栈来实现的abi为了更高的性能改为通过寄存器来实现)

综上,gomonkey的优点是方便快捷,但是在兼容性稳定性并发安全上具有不可忽视的问题。

依赖倒置

通过依赖倒置来让我们可以简单的实现构造一个"假函数"的目的。依赖倒置本质上就是将A->B的关系变为 A(interface{func B}),让我们可以通过依赖注入的方式让函数A屏蔽掉函数B的影响,举个例子

Golang 复制代码
// 更改前
func B(){
    anyPackage.C("arg")
}
func C(arg string){
    fmt.Println(arg)
}
// 更改为
type ServiceCIface interface {
    C(arg string)
}
type ServiceCImpl struct {}
func (s *ServiceCImpl) C(arg string){fmt.Println(arg)}
func B(srv ServiceCIface){
    srv.C(arg)
}
func A(){
    srv := newServiceCImpl()
    B(srv)
}

显然地,代码量多了几个量级,同时依赖注入本身对业务代码也有很强的侵入性,或许我的函数依赖了很多个函数,则会有如下问题:

  • 如果被依赖函数本身只是某个公共函数,那本不需要写对应的接口,这些代码对业务实现本身都是冗余的
  • 假设函数A依赖BCDE,那么在输入上可能增加了四个参数,可读性也会差很多。
  • 如果BCDE不属于同一个包,B包下也会用其他的函数 <math xmlns="http://www.w3.org/1998/Math/MathML"> B 1 B_1 </math>B1 <math xmlns="http://www.w3.org/1998/Math/MathML"> B 2 B_2 </math>B2, 为了省事可能会倾向写包括三个函数B, <math xmlns="http://www.w3.org/1998/Math/MathML"> B 1 B_1 </math>B1 <math xmlns="http://www.w3.org/1998/Math/MathML"> B 2 B_2 </math>B2 的大接口,但是单测mock时其实没必要实现函数 <math xmlns="http://www.w3.org/1998/Math/MathML"> B 1 B_1 </math>B1 <math xmlns="http://www.w3.org/1998/Math/MathML"> B 2 B_2 </math>B2。

综上:依赖注入安全稳定平台兼容性好,但是会添加很多冗余的代码,降低可读性。

相关推荐
重整旗鼓~31 分钟前
2.flask中使用装饰器统一验证用户登录
后端·python·flask
it噩梦1 小时前
springboot 工程使用proguard混淆
java·spring boot·后端
从种子到参天大树2 小时前
SpringBoot源码阅读系列(二):自动配置原理深度解析
后端
狠难说2 小时前
SpringCloud(八) - 自定义token令牌,鉴权(注解+拦截器),参数解析(注解+解析器)
后端
从种子到参天大树2 小时前
SpringBoot源码阅读系列(一):启动流程概述
后端
m0_748254882 小时前
Spring Boot实现多数据源连接和切换
spring boot·后端·oracle
庄周de蝴蝶2 小时前
一次 MySQL IF 函数的误用导致的生产小事故
后端·mysql
韩数3 小时前
Nping: 支持图表实时展示的多地址并发终端命令行 Ping
后端·rust·github
18号房客3 小时前
云原生后端开发(一)
后端·云原生
胡尔摩斯.4 小时前
SpringMVC
java·开发语言·后端·spring·代理模式