作为一名软件工程师，天然有着追求代码质量的执念。相信很多人对代码的优雅、质量有着自己的认识，业界也有不少的共识，其中有一条我认为是非常重要的——代码可测试。

作为一名研发，只关注功能可测（容易测）是远远不够的。从严谨的角度来看，我们每提交一个 PR（泛指有新的代码准备如何主分支）时，需要提供你已经测试通过的 “证据”。仅仅基于对团队成员的信任（或 QA 人员的回归测试）是很难从软件工程角度来保障代码质量的。研发 leader（或 QA）在面对 PR 时，可能会问到：你的代码自测过了吗？这也许是一个毫无意义的提问——可能很大一部分人会出于面子考虑直接回答” 测过了 “，另外一些诚实的人会说” 忘记了 “。在我看来，我们需要避免类似的无效、低效沟通；既然都是研发，那为什么不用测试代码来证明你的逻辑（或业务）代码的正确性呢？

单元测试、接口测试，是两种非常有效的、相对低成本的方法，前者可以确保函数的逻辑正确，后者可以确保 API 总是按照既定的输入和输出格式来处理。对于后端研发来说，能把这两种方法用起来的话，低级的、关联性的 bug 已经很难再流入到代码仓库的主干分支中了。API Testing 项目的发起，主要是为了持续提高我自己的代码质量，并且希望能帮助到有需要的其他人（研发或测试）。这个项目提供了诸如：命令行、CICD、VS-Code、浏览器等场景对接口测试的需求，目标是在尽量不改变已有研发习惯的前提下，使得大家可以便捷、简单地借助接口测试提高自己的代码质量。文中多次提到代码质量，本项目的后端 Golang 部分的单元测试覆盖率目前为 94%，之后也会持续提高测试覆盖率（包括前端等代码的）。

几周前，了解到 GLCC 这个活动还在招募开源项目。于是尝试联系官方负责人，咨询是否接受个人发起的开源项目（而且还是一个处在早期阶段的项目，截止本文只有 77 次 commit）。另外我感到惊喜和意外的是，这个项目不仅受到官方的认可与资助（完成项目议题的同学可以得到 6000 元奖励），而且还有 5 位同学对这个项目表示感兴趣，收到 4 份申请书。之后，我分别从多个维度尝试选择与项目匹配的申请人：是否在本项目中提交过 PR 或 issue、是否有邮件等沟通、议题设计、示例代码或 POC、GitHub 是否活跃、时间安排是否充足等（前面每一项的权重略有不同）。要知道，大部分同学都已经通过邮件和我进行了多次沟通，而且有两位同学也分别提交过 PR、issue，放弃任何一位申请人都是于心不忍的，因而我也尽量以相对客观的方式来做出选择。

让我印象比较深刻的是，屈晗煜 (Ink-33) 同学在申请书中给出了他对 gPRC 的一些调研结果，以及如何实现 gRPC 接口测试的大致思路，甚至还有一些实验性的代码。另外，他虽然只是大一新生，但编码经验却不少；能看得出来他确实是对编程很感兴趣。

最后，希望其他几位同学能匹配到其他项目，并能在参与开源的过程中有所收获。

↙↙↙阅读原文可查看相关链接，并与作者交流