一个 UT Failed 引出的思考

[[420832]]

本文转载自微信公众号「董泽润的技术笔记」，作者董泽润。转载本文请联系董泽润的技术笔记公众号。

前几天某个服务 ut 失败，导致别人无法构建。查看下源代码以及 ut case, 发现槽点蛮多，分享下如何修复，写单测要注意的一些点，由此引出设计模式中的概念依赖反转、依赖注入、控制反转

失败 case

func toSeconds(in int64) int64 { 
 if in > time.Now().Unix() { 
  nanosecondSource := time.Unix(0, in) 
  if dateIsSane(nanosecondSource) { 
   return nanosecondSource.Unix() 
  } 
 
  millisecondSource := time.Unix(0, in*int64(time.Millisecond)) 
  if dateIsSane(millisecondSource) { 
   return millisecondSource.Unix() 
  } 
 
  // default to now rather than sending something stupid 
  return time.Now().Unix() 
 } 
 return in 
} 
 
func dateIsSane(in time.Time) bool { 
 return (in.Year() >= (time.Now().Year()-1) && 
  in.Year() <= (time.Now().Year()+1)) 
} 

函数 toSeconds 接收一个时间参数，可能是秒、毫秒和其它时间，经过判断后返回秒值

...... 
  { 
 desc:   "less than now", 
 args:   1459101327, 
 expect: 1459101327, 
}, 
{ 
 desc:   "great than year", 
 args:   now.UnixNano()/6000*6000 + 7.55424e+17, 
 expect: now.Unix(), 
}, 
...... 

上面是 test case table, 最后报错 great than year 断言失败了。简单的看下实现逻辑就能发现，函数是想修正到秒值，但假如刚好 go gc STW 100ms, 就会导致 expect 与实际结果不符

如何从根本上修复问题呢?要么修改函数签名，外层传入 time.Now()

func toSeconds(in int64, now time.Time) int64 { 
  ...... 
} 

要么将 time.Now 函数定义成当前包内变量，写单测时修改 now 变量

var now = time.Now 
 
func toSeconds(in int64) int64 { 
 if in > now().Unix() { 
  ...... 
} 

以上两种方式都比较常见，本质在于单测 ut 不应该依赖于当前系统环境，比如 mysql, redis, 时间等等，应该仅依赖于输入参数，同时函数执行多次结果应该一致。去年遇到过 CI 机器换了，新机器没有 redis/mysql, 导致一堆 ut failed, 这就是不合格的写法

如果依赖环境的资源，那么就变成了集成测试。如果进一步再依赖业务的状态机，那么就变成了回归测试，可以说是层层递进的关系。只有做好代码的单测，才能进一步确保其它测试正常。同时也不要神话单测，过份追求 100% 覆盖

依赖注入

刚才我们非常自然的引入了设计模式中，非常重要的 依赖注入 Dependenccy injection 概念

func toSeconds(in int64, now time.Time) int64  

简单的讲，toSeconds 函数调用系统时间 time.Now, 我们把依赖以参数的形式传给 toSeconds 就是注入依赖，定义就这么简单

关注 DI, 设计模式中抽像出来四个角色：

• service 我们所被依赖的对像
• client 依赖 service 的角色
• interface 定义 client 如何使用 service 的接口
• injector 注入器角色，用于构造 service, 并将之传给 client

我们来看一下面像对像的例子，Hero 需要有武器，NewHero 是英雄的构造方法

type Hero struct { 
 name   string 
 weapon Weapon 
} 
 
func NewHero(name string) *Hero { 
 return &sHero{ 
  name:   name, 
  weapon: NewGun(), 
 } 
} 

这里面问题很多，比如换个武器 AK 可不可以呢?当然行。但是 NewHero 构造时依赖了 NewGun, 我们需要把武器在外层初始化好，然后传入

type Hero struct { 
 name   string 
 weapon Weapon 
} 
 
func NewHero(name string, wea Weapon) *Hero { 
 return &Hero{ 
  name:   name, 
  weapon: wea, 
 } 
} 
 
func main(){ 
 wea:= NewGun(); 
 myhero = NewHero("killer47", wea) 
} 

在这个 case 里面，Hero 就是上面提到的 client 角色，Weapon 就是 service 角色，injector 是谁呢?是 main 函数，其实也是码农

这个例子还有问题，原因在于武器不应该是具体实例，而应该是接口，即上面提到的 interface 角色

type Weapon interface { 
 Attack(damage int) 
} 

也就是说我们的武器要设计成接口 Weapon, 方法只有一个 Attack 攻击并附带伤害。但是到现在还不是理想的，比如说我没有武器的时候，就不能攻击人了嘛?当然能，还有双手啊，所以有时我们要用 Option 实现默认依赖

type Weapon interface { 
 Attack(damage int) 
} 
 
type Hero struct { 
 name   string 
 weapon Weapon 
} 
 
func NewHero(name string, opts ...Option) *Hero { 
 h := &Hero{ 
  name: name, 
 } 
 
 for _, option := range options { 
  option(i) 
 } 
 
 if h.weapon == nil { 
  h.weapon = NewFist() 
 } 
 return h 
} 
 
type Option func(*Hero) 
 
func WithWeapon(w Weapon) Option { 
 return func(i *Hero) { 
  i.weapon = w 
 } 
} 
 
func main() { 
 wea := NewGun() 
 myhero = NewHero("killer47", WithWeapon(wea)) 
} 

上面就是一个生产环境中，比较理想的方案，看不明白的可以运行代码试着理解下

第三方框架

刚才提到的例子比较简单，injector 由码农自己搞就行了。但是很多时候，依赖的对像不只一个，可能很多，还有交叉依赖，这时候就需要第三方框架来支持了

 <?xml version="1.0" encoding="UTF-8"?> 
 <beans xmlns="http://www.springframework.org/schema/beans" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.springframework.org/schema/beans 
  http://www.springframework.org/schema/beans/spring-beans-3.0.xsd"> 
 
    <bean id="service" class="ExampleService"> 
    </bean> 
 
    <bean id="client" class="Client"> 
        <constructor-arg value="service" />         
    </bean> 
</beans> 

Java 党写配置文件，用注解来实现。对于 go 来讲，可以使用 wire, https://github.com/google/wire

// +build wireinject 
 
package main 
 
import ( 
    "github.com/google/wire" 
    "wire-example2/internal/config" 
    "wire-example2/internal/db" 
) 
 
func InitApp() (*App, error) { 
    panic(wire.Build(config.Provider, db.Provider, NewApp)) // 调用wire.Build方法传入所有的依赖对象以及构建最终对象的函数得到目标对象 
} 

类似上面一样，定义 wire.go 文件，然后写上 +build wireinject 注释，调用 wire 后会自动生成 injector 代码

//go:generate go run github.com/google/wire/cmd/wire 
//+build !wireinject 
 
package main 
 
import ( 
    "wire-example2/internal/config" 
    "wire-example2/internal/db" 
) 
 
// Injectors from wire.go: 
 
func InitApp() (*App, error) { 
    configConfig, err := config.New() 
    if err != nil { 
        return nil, err 
    } 
    sqlDB, err := db.New(configConfig) 
    if err != nil { 
        return nil, err 
    } 
    app := NewApp(sqlDB) 
    return app, nil 
} 

我司有项目在用，感兴趣的可以看看官方文档，对于构建大型项目很有帮助

依赖反转 DIP 原则

我们还经常听说一个概念，就是依赖反转 dependency inversion principle, 他有两个最重要的原则：

• High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g., interfaces).
• Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

高层模块不应该依赖低层模块，需要用接口进行抽像。抽像不应该依赖于具体实现，具体实现应该依赖于抽像，结合上面的 Hero&Weapon 案例应该很清楚了

那我们学习 DI、DIP 这些设计模式目的是什么呢?使我们程序各个模块之间变得松耦合，底层实现改动不影响顶层模块代码实现，提高模块化程度，增加括展性

但是也要有个度，服务每个都做个 interface 抽像一个模块是否可行呢?当然不，基于这么多年的工程实践，我这里面有个准则分享给大家：易变的模块需要做出抽像、跨 rpc 调用的需要做出抽像

控制反转 IOC 思想

本质上依赖注入是控制反转 IOC 的具体一个实现。在传统编程中，表达程序目的的代码调用库来处理通用任务，但在控制反转中，是框架调用了自定义或特定任务的代码，Java 党玩的比较多

推荐大家看一下 coolshell 分享的 undo 例子。比如我们有一个 set 想实现 undo 撤回功能

type IntSet struct { 
    data map[int]bool 
} 
func NewIntSet() IntSet { 
    return IntSet{make(map[int]bool)} 
} 
func (set *IntSet) Add(x int) { 
    set.data[x] = true 
} 
func (set *IntSet) Delete(x int) { 
    delete(set.data, x) 
} 
func (set *IntSet) Contains(x int) bool { 
    return set.data[x] 
} 

这是一个 IntSet 集合，拥有三个函数 Add, Delete, Contains, 现在需要添加 undo 功能

type UndoableIntSet struct { // Poor style 
    IntSet    // Embedding (delegation) 
    functions []func() 
} 
  
func NewUndoableIntSet() UndoableIntSet { 
    return UndoableIntSet{NewIntSet(), nil} 
} 
  
func (set *UndoableIntSet) Add(x int) { // Override 
    if !set.Contains(x) { 
        set.data[x] = true 
        set.functions = append(set.functions, func() { set.Delete(x) }) 
    } else { 
        set.functions = append(set.functions, nil) 
    } 
} 
func (set *UndoableIntSet) Delete(x int) { // Override 
    if set.Contains(x) { 
        delete(set.data, x) 
        set.functions = append(set.functions, func() { set.Add(x) }) 
    } else { 
        set.functions = append(set.functions, nil) 
    } 
} 
func (set *UndoableIntSet) Undo() error { 
    if len(set.functions) == 0 { 
        return errors.New("No functions to undo") 
    } 
    index := len(set.functions) - 1 
    if function := set.functions[index]; function != nil { 
        function() 
        set.functions[index] = nil // For garbage collection 
    } 
    set.functions = set.functions[:index] 
    return nil 
} 

上面是具体的实现，有什么问题嘛?有的，undo 理论上只是控制逻辑，但是这里和业务逻辑 IntSet 的具体实现耦合在一起了

type Undo []func() 
 
func (undo *Undo) Add(function func()) { 
  *undo = append(*undo, function) 
} 
func (undo *Undo) Undo() error { 
  functions := *undo 
  if len(functions) == 0 { 
    return errors.New("No functions to undo") 
  } 
  index := len(functions) - 1 
  if function := functions[index]; function != nil { 
    function() 
    functions[index] = nil // For garbage collection 
  } 
  *undo = functions[:index] 
  return nil 
} 

上面就是我们 Undo 的实现，跟本不用关心业务具体的逻辑

type IntSet struct { 
    data map[int]bool 
    undo Undo 
} 
  
func NewIntSet() IntSet { 
    return IntSet{data: make(map[int]bool)} 
} 
 
func (set *IntSet) Undo() error { 
    return set.undo.Undo() 
} 
  
func (set *IntSet) Contains(x int) bool { 
    return set.data[x] 
} 
 
func (set *IntSet) Add(x int) { 
    if !set.Contains(x) { 
        set.data[x] = true 
        set.undo.Add(func() { set.Delete(x) }) 
    } else { 
        set.undo.Add(nil) 
    } 
} 
  
func (set *IntSet) Delete(x int) { 
    if set.Contains(x) { 
        delete(set.data, x) 
        set.undo.Add(func() { set.Add(x) }) 
    } else { 
        set.undo.Add(nil) 
    } 
} 

这个就是控制反转，不再由控制逻辑 Undo 来依赖业务逻辑 IntSet, 而是由业务逻辑 IntSet 来依赖 Undo. 想看更多的细节可以看 coolshell 的博客

再举两个例子，我们有 lbs 服务，定时更新司机的坐标流，中间需要处理很多业务流程，我们埋了很多 hook 点，业务逻辑只需要对相应的点注册就可以了，新增加业务逻辑无需改动主流程的代码

很多公司在做中台，比如阿里做的大中台，原来各个业务线有自己的业务处理逻辑，每条业务线都有工程师只写各自业务相关的代码。中台化会抽像出共有的流程，每个新的业务只需要配置文件自定义需要的哪些模块即可，这其实也是一种控制反转的思想