共计 3447 个字符，预计需要花费 9 分钟才能阅读完成。
近日，极狐(GitLab) 江狐会第十四期在北京圆满闭幕。
会上，途游游戏运维安全部研发负责人刘勇 基于应用 极狐 GitLab 进步单元测试 ROI 的实际与领会 ，进行了《途游游戏麻利开发工程实际》 主题分享，为线上线下泛滥云计算用户、企业 IT 和运维工程师、架构师、开发者，以及开源和 DevOps 的爱好者们提供一些参考。
本文整顿自途游游戏刘勇分享的核心内容，欢送在 公众号【极狐 GitLab】首页音讯对话栏回复“途游”获取 PPT，enjoy～
单元测试在麻利开发流程中有什么意义？
单元测试是指对软件中的最小可测试单元进行检查和验证，一个单元测试就是一段自动化代码，这段代码调用被测试的指标单元，查看指标单元的行为是否合乎开发人员的预期。
如图 1 所示，单元测试处于测试金字塔的最底层，也就是软件研发的晚期阶段，属于白盒测试，是开发的组成部分。
图 1
那么，单元测试在麻利开发流程中有什么意义呢？
从研发品质角度思考
麻利的外围即拥抱变动，但变动带来危险。无论是因为重构、需要变更或其余导致代码必须要变更的时候，单元测试能够第一工夫发现变更的代码是否会对业务逻辑造成破坏性的影响，这是单元测试最大的价值——守护程序的业务逻辑。
第二，“Talk is cheap，show me the code”，单元测试为研发人员 提供了被测试代码的性能和应用案例 ，相当于更具体的文档，可能对 改善代码构造 产生踊跃的影响。
第三，有了高质量的单元测试，开发人员 能够对已有代码进行有信念的变更，不论这种变更来自于业务和需要的变动，还是来自于重构。
最初，任何看起来难以测试的代码也将难以保护、倒退，并且在其整个生命周期中都会受到许多谬误的影响。因而，单元测试促使开发人员从新思考他们的编码方式，晋升编码品质。
从测试的经济学角度思考
如图 2 所示，85% 的 Bug 在 Coding 阶段产生，而传统的测试人员往往集中在 Function Test（功能测试）、System Test（系统集成测试）阶段，这些阶段修复 Bug 的老本数十倍减少，公布后的修复老本达到惊人数百倍。
图 2
Bug 发现的越早，修复老本就越低。前期 Bug 的修复不仅减少沟通工夫，还可能引入新的问题，减少测试验证工夫，我的项目的进度也有提早上线的危险。
因而，咱们要尽可能地把测试左移，在软件开发的晚期阶段通过单元测试发现 Bug，更低成本解决 Bug，进步代码品质，优化测试过程的投资回报率。
图 3
总而言之，单元测试杠杠好！
那么如何施行单元测试？
基于极狐 GitLab 的单元测试四步法
途游游戏应用极狐 GitLab 进行软件研发实际，刘勇有一个粗浅领会：极狐 GitLab 可能很好地帮忙你将破费很多精力、工夫和老本，好不容易写出的单元测试的价值充沛开掘进去。
图 4
首先答复一个问题：单元测试放在哪里？
能够放在独自目录里，如 Java，Maven tests 目录、Package 和被测代码在一起；也能够和源代码在一起，如 Golang。原则上要尽可能离源码近。
如何施行单元测试？刘勇演绎了 单元测试四步骤（AAAC）：
- Arrange 筹备：为测试做筹备；
- Act 执行：给予特定行为所需的上下文和输出并执行；
- Assert 断言：判断后果是否合乎预期；
- Clear 清理环境：为后续测试保障上下文洁净，测试之间彼此隔离没有依赖性。
1. Arrange 筹备：编写单元测试
Arrange 阶段就像多米诺骨牌之前的排列工作，为了接下来的行为能够被激发，包含但不限于筹备所需的输出（对象、根底数据结构等）、启动 / 终止某服务如 MQ 或数据库、将一些数据事后存入数据库，为尚不存在的用户生成一些凭据等的事件。
极狐 GitLab 有一个性能就是能够在容器里边提供很多预置的 Service，让数据库也好，MQ 也好，都能够很轻松地事后筹备好。这样的话，当你在测试一个函数的时候，它的环境、数据库都会主动在你的 CI 环境中就绪，大幅晋升单元测试的效率，是很贴心的服务。
单元测试准则参考
- 每个测试范畴职责繁多（不要试图用一个测试函数测试 10 个性能点）
- 执行速度快（总体执行工夫不超过 5 分钟，单个用例执行工夫 3 秒以内，TDD 闭环工夫）
- 自动化测试思路，防止人工查看，比方用 assert 代替 print 信息人眼辨认后果
- 良好设计并命名的可复用单元测试体系
- 测试能够很容易的在 CI 流水线中在程序员的开发机上运行，不须要搭建或者很容易自动化搭建所需的测试环境
- 单元测试执行后果稳固，一个 10 次执行，8 次通过 2 次失败的单元测试是谬误的
- 每一个测试函数所依赖的单元测试的环境应该是固定并洁净的，测试函数彼此隔离，一个测试函数所依赖的环境不能是另一个测试函数执行后的后果
2. Act 执行：利用单元测试
Act 阶段对应多米诺骨牌，即是指尖微微推动第一块触发牌。费了很多的工夫和精力，终于写完了单元测试，也能跑了，这个时候咱们怎么去用它呢？
首先来看极狐 GitLab 上的工作流（如图 4），途游游戏在此基础上稍加改变：把代码 Commit 之后，Push 到咱们远端的服务仓库时会进行一次单元测试执行，在合并的时候会进行第二次次单元测试执行，在合并之后还会进行第三次单元测试执行。
图 5
咱们如何管制单元测试在何时执行？途游游戏在极狐 GitLab 上有两种触发形式，别离是：
（1）代码合并到主分支之前，每次代码 Push 到 MR 源分支，并基于合并后的代码（极狐 Gitlab Merge Request Pipeline + Merge Result Pipelines）
首先，咱们有一个主分支，往往是 Main 分支。这时候，如果咱们要开发一个新性能，可依据这个新性能创立一个 Feature Branch 即个性分支，程序员会工作在个性分支上。
接着，咱们会一直 Commit 代码，并且 Push 到在极狐 GitLab 上创立的个性分支上，这个时候就会触发单元测试执行。
个别的 CI 工具只会执行在 Source Branch 上，就是源分支上，但极狐 GitLab 有一个性能叫做 Merge Result Pipeline，这是一个独特的性能，它的单元测试是跑在个性分支和组分支合并之后的代码上，而不须要你进行真正的合并，防止在个性分支的开发过程中，有其余人员抢先一步，在主分支上合并了其余的代码，而导致你的代码合并失败。
这也是途游游戏所秉承的“测试前置”，即利用极狐 GitLab 的 Merge Request Pipeline + Merge Result Pipeline 在个性分支上就发现问题，尽早解决问题。
（2）代码合并到主分支之后（CI/CD 之前）
此时，途游游戏再次执行单元测试来守护代码，这里用到了 极狐 GitLab 的另一个性能：Job。一个形象 Job 相当于“类”，自身不会实例化，也不会真正地执行。做法是在后面加一个“.”。
这样做的基本指标在于，须要在两种状况下执行同一个 Job，也就是 .unittest 这个 Job。这两种触发条件为：
- 有新的代码被提交到某一个 Merge Request 的源分支上
- 代码被合并到默认分支后
图 6
3. Assert 断言：查看单元测试后果
单元测试的后果包含了测试覆盖率，以及若测试失败，其失败的后果。具体不同的语言，不同的测试框架，有不同的实现形式。
以 pytest 实现形式为例（如图 6），前面四行就是该单元测试的报告，用来掂量单元测试胜利与否；前缀是与测试覆盖率相干的一些货色，在极狐 GitLab 界面上能够看到这个后果，实现单元测试用例执行后果的可视化。
pytest itom_cmdb_tests/
--create-db
--migrations
--vcr-record none
--junitxml=test_reports/itom_cmdb_testcase_report.xml
--cov-report xml:test_reports/coverage.xml
--cov-report term
--cov=itom_cmdb itom_cmdb_tests/tests/图 7 展现的是极狐 GitLab 的 Merge Request 的 Code Review 视图：绿色杠杆就是有单元测试的一些代码，红色是单元测试没有笼罩到的代码。极狐 GitLab 会主动获取相应信息，并且上传到极狐 GitLab 的环境当中。
图 7
4. Clear 清理：革除单元测试环境
在单元测试最初阶段，须要清理测试环境，例如还原全局配置、清理创立的文件目录等，为后续测试保留洁净的上下文，确保测试之间彼此隔离没有依赖性。
以上就是途游游戏运维安全部研发负责人刘勇分享的单元测试次要内容，欢送关注极狐 GitLab 继续获取各类技术干货！
