这是我参与「第三届青训营 -后端场」笔记创作活动的第1篇笔记

测试分类

例子

func Njie(n int) int {
	if n == 0 || n == 1 {
		return 1
	}
	return n * Njie(n-1)
}

func TestNjie(t *testing.T) {

	if Njie(5) != 120 {
		t.Log("Njie(5)!=120")
	} else {
		t.Log("Njie(5)==120")
	}
}

测试文件规则

文件使用_test.go结尾
函数是以Test开头
初始化逻辑放在TestMain

测试核心

-----测试的覆盖率

go test try_test.go --cover

--cover可以显示处test的覆盖率

Tips

一般覆盖率-----50%~60%，较高的是80+%以上

测试分支相互独立、全面覆盖

测试单元粒度足够小，函数单一职责

依赖

file，db，cache都是强依赖

单元测试目标

幂等---每次测试相同

稳定---测试相互隔离的

Mock机制

替换函数

git clone github.com/bouk/monkey…

基准测试

github.com/bytedance/g…

作用

测试一个程序运行时的性能，和CUP的损耗

规则

和单元测试是一致的，

文件是以bench_test.go结尾

函数是以Benchmark开头

例子

func BenchmarkFib(b *testing.B) {
	b.ResetTimer()
	fmt.Println("b.N=", b.N)
	for i := 0; i < b.N; i++ {
		fmt.Println("fib(", i, ")=", nont.Fib(20))
	}
}

运行

指定运行BenchmarkFib

go test -bench="BenchmarkFib"

go test -bench=.

运行这个包下所有Benchmark函数

依赖

Go依赖的发展

GOPATH--->GO vendor--->GO module

GOPATH

模式

bin----二进制文件
pkg----编译的中间产物
src----源码

弊端

无法实现package的多版本控制

GO vendor

模式

依赖放在vendor，先在vendor找，找不到再去GOPATH找

弊端

无法控制依赖的版本

GO module

模式

通过go.mod文件管理依赖包版本

通过go get/go mod 指令工具管理依赖包

go.mod文件

indirect是间接依赖，即没有直接使用

若不同项目之间，都依赖了一个项目但又不同版本，go会自动选择最低兼容版本

版本规定

语义化版本

${major}.$ {minor}.${patch}------大版本（可以不兼容，可以认为是隔离的）---新增函数/功能-----BUG修复

如，V1.3.0 V2.3.0

基于commit伪版本

vx.0.0-yyyymmddhhmmss-adcefgh1234

版本前缀----时间戳-----哈希码

依赖管理三要素

配置文件，描述依赖 go.mod
中心仓库管理依赖库 Proxy
本地工具 go get/mod

依赖分发-Proxy-回源

作用

缓存源文件中的内容，缓存的版本不会改变

配置

GOPROXY="url1,url2,……,direct"

依次寻找

direct表示如果前面的站点都没有依赖，就回到第三方代码源站

go get

如

go get -u github.com/easierway/concurrent_map

-u 会自动更新版本

go mod

初始化自己的项目

- 首先go mod init 项目路径

下载别人的项目

- 首先go mod tidy，下载好依赖

【青训营】go的测试和依赖