本文转载自微信公众号「董泽润的技术笔记」,作者董泽润。转载本文请联系董泽润的技术笔记公众号。
前几天某个服务 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))
}
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
函数 toSeconds 接收一个时间参数,可能是秒、毫秒和其它时间,经过判断后返回秒值
......
{
desc: "less than now",
args: 1459101327,
expect: 1459101327,
},
{
desc: "great than year",
args: now.UnixNano()/6000*6000 + 7.55424e+17,
expect: now.Unix(),
},
......
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
上面是 test case table, 最后报错 great than year 断言失败了。简单的看下实现逻辑就能发现,函数是想修正到秒值,但假如刚好 go gc STW 100ms, 就会导致 expect 与实际结果不符
如何从根本上修复问题呢?要么修改函数签名,外层传入 time.Now()
func toSeconds(in int64, now time.Time) int64 {
......
}
- 1.
- 2.
- 3.
要么将 time.Now 函数定义成当前包内变量,写单测时修改 now 变量
var now = time.Now
func toSeconds(in int64) int64 {
if in > now().Unix() {
......
}
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
以上两种方式都比较常见,本质在于单测 ut 不应该依赖于当前系统环境,比如 mysql, redis, 时间等等,应该仅依赖于输入参数,同时函数执行多次结果应该一致。去年遇到过 CI 机器换了,新机器没有 redis/mysql, 导致一堆 ut failed, 这就是不合格的写法
如果依赖环境的资源,那么就变成了集成测试。如果进一步再依赖业务的状态机,那么就变成了回归测试,可以说是层层递进的关系。只有做好代码的单测,才能进一步确保其它测试正常。同时也不要神话单测,过份追求 100% 覆盖
依赖注入
刚才我们非常自然的引入了设计模式中,非常重要的 依赖注入 Dependenccy injection 概念
func toSeconds(in int64, now time.Time) int64
- 1.
简单的讲,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(),
}
}
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
这里面问题很多,比如换个武器 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)
}
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
在这个 case 里面,Hero 就是上面提到的 client 角色,Weapon 就是 service 角色,injector 是谁呢?是 main 函数,其实也是码农
这个例子还有问题,原因在于武器不应该是具体实例,而应该是接口,即上面提到的 interface 角色
type Weapon interface {
Attack(damage int)
}
- 1.
- 2.
- 3.
也就是说我们的武器要设计成接口 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))
}
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
上面就是一个生产环境中,比较理想的方案,看不明白的可以运行代码试着理解下
第三方框架
刚才提到的例子比较简单,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>
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
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方法传入所有的依赖对象以及构建最终对象的函数得到目标对象
}
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
类似上面一样,定义 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
}
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
我司有项目在用,感兴趣的可以看看官方文档,对于构建大型项目很有帮助
依赖反转 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]
}
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
这是一个 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
}
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
上面是具体的实现,有什么问题嘛?有的,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
}
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
上面就是我们 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)
}
}
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
这个就是控制反转,不再由控制逻辑 Undo 来依赖业务逻辑 IntSet, 而是由业务逻辑 IntSet 来依赖 Undo. 想看更多的细节可以看 coolshell 的博客
再举两个例子,我们有 lbs 服务,定时更新司机的坐标流,中间需要处理很多业务流程,我们埋了很多 hook 点,业务逻辑只需要对相应的点注册就可以了,新增加业务逻辑无需改动主流程的代码
很多公司在做中台,比如阿里做的大中台,原来各个业务线有自己的业务处理逻辑,每条业务线都有工程师只写各自业务相关的代码。中台化会抽像出共有的流程,每个新的业务只需要配置文件自定义需要的哪些模块即可,这其实也是一种控制反转的思想