测试与交付
实现完成不等于可交付。本章为服务补齐三层保障:单元与接口测试、容器化部署、CI 流水线。
测试落地
单元层:短码生成(表驱动)
单元层:业务规则(fake 替身)
验证自定义短码校验与冲突重试,不触碰数据库:
接口层:httptest 验证路由与状态码
Tip
newFakeLinkStore / newFakeUserStore 是存储接口的内存实现(参考测试章的 fake 模式),篇幅原因省略——它们与 internal/service/link_test.go 中的 fake 同构。接口测试不连真实数据库,整套测试在毫秒级完成。
Docker Compose 部署
Dockerfile 沿用工程化章的多阶段模板,Compose 负责把应用与数据库编排起来:
Tip
Compose 要点:depends_on + healthcheck 保证启动顺序正确(只靠 depends_on 只保证"已启动"而非"已就绪");数据库数据落在命名卷,docker compose down 不丢数据,down -v 才会清空。生产环境的 JWT_SECRET、数据库口令绝不应写在 Compose 文件里,应注入环境或密钥管理服务。
CI 流水线
.github/workflows/ci.yml(工程化章模板的直接落地):
后续可按需扩展:构建成功后推送镜像到镜像仓库(docker buildx + docker/login-action),再自动部署到目标环境。
交付检查清单
上线前逐项自检:
-
go test -race ./...全绿,覆盖率了解于心 -
golangci-lint run零告警 - 密钥全部来自环境变量,代码与仓库中无硬编码
-
/metrics、pprof 等管理端点不会暴露公网 - 优雅退出验证过(
docker compose stop观察日志) - 限流、404、401 等负路径手工验证过
- 日志输出 JSON 且不含敏感信息
小结
- 测试分三层落地:表驱动单测 → fake 替身业务测试 → httptest 路由状态码验证,全程毫秒级。
- Compose 的
healthcheck+depends_on: condition是多服务启动顺序的正确解法。 - CI 是工程化的收口:vet → test -race → lint → build,配好一次全程受益。
项目完成。 回顾整个学习路径:从 go mod init 的第一个 Hello World,到并发模型、Web 服务,再到这个可部署的完整服务与 langchaingo 的 LLM 应用——你已经具备了独立开发 Go 生产代码的全部基础。接下来最好的学习方式,是开始写你自己的真实项目。