把集成测试和单元测试写一起是一种什么体验?

今日想跟咱们共享一下最近咱们在单元测验和集成测验上的一些心得。

咱们是归于不到两个披萨就能吃饱的团队,严格来说,一个披萨就够了,首要因为咱们有怕胖的女孩子和不吃高热量的老年人。尽管咱们人丁并不兴隆,可是咱们担任着七个项目,有两个是春节前确认的,我后文中称它俩为A和B。到目前为止,A和B现已运转了两个sprint。

B是内部服务,它并不直接服务于用户,而是服务于公司内的其他项目,比方A项目。A是直接服务于用户的,可是A的稳定性必定程度上依赖于B的稳定性。所以假如咱们要确保A和B的质量,那么就要做好B的单元测验,A的单元测验和A的集成测验。这儿就有个问题,咱们人丁单薄,在确保覆盖率的前提下,怎样能够少做一些操作呢?所以咱们自己探索了一条路,把A的单元测验和集成测验写到一同!

详细的思路是这样,咱们发动单元测验的指令是 npm run test ,然后经过环境变量、参数或其他发动指令在同一个发动进口发动集成测验,比方咱们用 npm run integration 来发动集成测验。当运转集成测验时,程序主动加载test/specs/ 目录下以.spec.ts完毕的文件,当运转单元测验时,程序主动加载test/specs/ 目录下以.spec.ts一起不以.integration.spec.ts完毕的文件。

紧接着要处理第二个问题,写单元测验时,遇到其他模块或外部服务,咱们一般把它们mock掉。可是在集成测验时,就需要真刀真枪的与外部服务交互。所以在上图的 environment 文件夹中咱们供给了一些类和办法,构建测验时所需的全部环境,比方运用docker发动db、redis和B服务。

这样今后,无论是单元测验仍是集成测验,每一条case该怎样写就怎样写,程序理应和实在环境中的运转作用相同。

然后,咱们就要开端处理第三个问题,怎样能够确保咱们在本地获取到B服务的镜像?为此咱们和运维同学交流后,为指定IP地址开放了一个私有镜像库房,在B服务的CD流水线完结制品job时,把B服务的镜像向咱们的私有库房推一份,然后咱们经过个人账号,能够从这个库房中主动下载B服务的镜像。这时A项目集成测验所需的全部条件都安排妥当了,这是咱们实践的运转作用:

因为春节后刚运转了两个sprint,cases数还不够多,可是咱们的覆盖率现已保持在93%以上。B项目的单元测验覆盖率也是93%以上:

集成测验运转完毕后,不要忘了铲除不需要的container和volume。

这个计划施行起来仍是挺顺畅的,尽管有些小问题,可是基本上1-2天结构就建立起来了。剩余的便是继续弥补和继续维护测验cases。

当然单元测验和集成测验是根底,还需要经过恰当的流程让它们发挥更大的价值。咱们的代码库房运用的是github,根据github的pull request,每次有同学想提交代码到主分支,只能经过PR的方法。提交PR时会主动触发咱们的CI,运转代码质量剖析和单元测验。要想PR经过,至少有一个人在code review后点了approve按钮。而咱们内部有要求,无论是feature和bug,有必要要有相关的单元测验或许集成测验,一起也有对覆盖率的要求。经过环环相扣,终究把咱们的A服务和B服务的质量维护起来。

将近一个月的长途工作,咱们并没有在交流、协作上呈现什么问题,团队之间仍是非常信赖。一部分归功于咱们写程序的人相对来说比较简略,大多数时刻都是关闭在自己的思维里。还有一部分归功于咱们团队一向对DevOps的工程化实践非常重视,比方项目初期必定要把集成测验搞起来,让CI/CD成为柱石。不过最重要的一部分,当然是咱们一向用咱们自己的产品Worktile。一个身世于协作,致力于研制更简略的团队,这点事算事吗?

Worktile 官网: worktile.com

本文作者:孙敬云

文章首发于「 Worktile官方博客 」,转载请注明出处。

时间

2020-08-03 00:38


栏目

网络建站


作者

admin


分享