class 2-1

配置文件，描述依赖

GOPATH:

bin: 二进制文件 pkg: 中间产物，加速编译 src: 项目源码

项目代码直接依赖src下的代码 go get下载最新版本包到src目录下

弊端：无法实现package的多版本控制

Go Verdor：

在项目目录下增加vendor文件，存放了依赖包的副本，优先副本，如果副本丢失，在回到GOPATfH下寻找，接近了多版本控制问题。问题：项目B，C分别依赖D的v1和v2版本，但是他们都去读取各自的副本，不知该如何选择D的版本，产生冲突，可能会造成编译错误。弊端：更新项目时可能出现冲突，没有清晰表明依赖版本

Go Module：

通过go.mod管理依赖包版本通过go get/go mod指令工具管理依赖包终极目标：定义版本规则和管理项目依赖关系

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

依赖配置-go.mod

module example/project/app #依赖管理单元

go 1.16 #原生库

require(
    example/lib1 v1.0.2
    example/lib2 v1.0.0
   #[modulePath] [Version]
   )

go mod定义了版本规则

语义化版本

Major.Minor.Patch

eg. V1.3.0

Major间可以互相不兼容（代码隔离），Minor是兼容增减/修复，Patch一般是代码修复

基于commit的伪版本

版本前缀-提交commit时的时间戳-提交commit的12位哈希码前缀

vx0.0-yyyymmddhhmmss-abcdefgh1234

eg. v1.0.0-20230726230224-10cb98267c6c

//indirect 间接依赖标识

+incompatible major层面不兼容标识

解决go vendor的问题：若A依赖于C1.2, B依赖于C1.3, 则最终调用的是C1.3版本。因为都是v1版本，默认可兼容，选择最低/最新的兼容版本。

中心仓库管理依赖库 - 依赖分发

直接调用第三方（压力大）：Github/SVN --> Developer

解决方法：Go Proxy 缓存/代理

Github/SVN --> Proxy --> Developer 稳定&可靠

GOPROXY = "http://proxy1,cn, proxy2.cn, direct"

proxy1 --> proxy2 --> direct

服务站点URL列表，direct表示源站

辅助依赖管理的工具 - go get/mod

go get example.org/pkg

@update 默认
@none 删除依赖
@v1.1.2 tag版本，语义版本
@23dfdd5 特定的commit
@master 分支的最新commit

go mod

init 初始化，创建go.mod文件
download 下载模块到本地缓存
tidy 增加需要的依赖，删除不需要的依赖，释放空间，节省资源

Class 2.2

测试

回归测试
集成测试
单元测试

由上至下，成本降低，覆盖率增加

单元测试

测试函数/模块，校对输入输出，提升效率，保证质量（覆盖率）

规则：

所有测试文件以_test.go结尾
命名规则 func TestXxx(*testing.T)
初始化逻辑放到TestMain中

func TestMain(m *testing.M) {
    //测试前：数据装载、配置初始化等前置工作
    code := m.Run()
    //测试后：释放资源等收尾工作
    os.Exit(code)
}

assert函数可判断＝/≠

如何评估项目测试达标：代码覆盖率

--cover 即可显示覆盖率

实际覆盖率50%-60%，较高为80%（资金类，成本较高）
测试分支相互独立、全面覆盖
测试单元粒度足够小，函数单一职责

第2课笔记：Go语言工程实践——依赖配置与测试|青训营