本文探讨了如何将Go单元测试集成到GitLabCI中，以解决单测代码维护的难题。通过GitLabCI，每次push代码都会自动运行测试并展示结果。文章提出使用覆盖率作为量化指标推动单测的实施，并展示了如何在项目中设置覆盖率徽章和覆盖率阈值，以确保代码质量。此外，还介绍了包含lint检查在内的完整GitLabCI配置文件。
- Go单元测试实践一，快速上手
- Go单元测试实践二，常见问题
- Go 单元测试实践四，集成到gitlabci
之前的文章介绍了怎么写单测，这篇文章讨论如何将单测集成到开发流程中。
单测代码的维护难题
如果单测代码仅在开发时运行一次，会有下面的问题： 1. 场景1：功能更新 -> 开发调整了源码，但没有重新运行配套单测 -> 单测代码没有及时更新，处于实质上不通过的状态 -> 单测代码腐坏、废弃 2. 场景2：功能更新 -> 开发调整了源码，不小心写了bug -> 由于没有运行单测，开发没发现 -> 单测没有起到作用
解决办法：引入gitlabci，gitlabci可以做什么？简单概括就是：
- 每当你向远程push新代码，都会自动触发一段程序，称为pipeline
- 这段逻辑的结果可以为 成功/失败
- 执行结果会展示在
merge request界面，reviewer能看到 - 一般会规定一个mr只有pipelin通过才可合入，由此确保master的单测始终pass
ci工具有很多，功能类似，我们公司使用gitlab作为代码管理平台，因此选择了它提供的gitlabci功能。gitlabci文档
单测推广的量化难题
- 有的开发会因为 "不认可单测的价值"，"不习惯" 等原因，不愿意写单测。需要一个量化指标push大家。
- 需要一个量化指标反映单测推广的工作进度，便于
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
