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

作为一名研发,只关注功能可测(容易测)是远远不够的。从严谨的角度来看,我们每提交一个 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 接口测试的大致思路,甚至还有一些实验性的代码。另外,他虽然只是大一新生,但编码经验却不少;能看得出来他确实是对编程很感兴趣。

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

本文相关链接:

https://github.com/Ink-33
https://github.com/LinuxSuRen/api-testing/issues/81
https://www.gitlink.org.cn/glcc/2023/subjects/detail/656
https://www.gitlink.org.cn/linuxsuren/api-testing/issues/1


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