跳到主要内容

1 篇博文 含有标签「测试框架」

查看所有标签

高效测试框架推荐之Ginkgo

· 阅读需 9 分钟
CarlJi
Coder|Blogger|Engineer|Mentor

自 2015 年开始,七牛工效团队一直使用 Go 语言+Ginkgo的组合来编写自动化测试用例,积累了大约 5000+的数量。在使用和维护过程中,我们觉得 Ginkgo 的很多设计理念和功能非常赞,因此特分享给大家。

本篇不是该框架的入门指导。如果您也编写或维护过大量自动化测试用例,希望能获得一些共鸣.

BDD(Behavior Driven Development)

要说 Ginkgo 最大的特点,笔者认为,那就是对 BDD 风格的支持。比如:

	Describe("delete app api", func() {
It("should delete app permanently", func() {...})
It("should delete app failed if services existed", func() {...})

It's about expressiveness。Ginkgo 定义的 DSL 语法(Describe/Context/It)可以非常方便的帮助大家组织和编排测试用例。在 BDD 模式中,测试用例的标题书写,要非常注意表达,要能清晰的指明用例测试的业务场景。只有这样才能极大的增强用例的可读性,降低使用和维护的心智负担。

可读性这一点,在自动化测试用例设计原则上,非常重要。因为测试用例不同于一般意义上的程序,它在绝大部分场景下,看起来都像是一段段独立的方法,每个方法背后隐藏的业务逻辑也是细小的,不具通识性。这个问题在用例量少的情况下,还不明显。但当用例数量上到一定量级,你会发现,如国能快速理解用例到底是能做什么的,真的非常重要。而这正是 BDD 能补足的地方。

不过还是要强调,Ginkgo 只是提供对 BDD 模式的支持,你的用例最终呈现的效果,还是依赖你自己的书写。

进程级并行,稳定高效

相应的我们知道,BDD 框架,因为其 DSL 的深度嵌套支持,会存在一些共享上下文的资源,如此的话想做线程级的并发会比较困难。而 Ginkgo 巧妙的避开了这个问题,它通过在运行时,运行多个被测服务的进程,来达到真正的并行,稳定性大大提高。其使用姿势也非常简单,ginkgo -p命令就可以。在实践中,我们通常使用 32 核以上的服务器来跑集测,执行效率非常高。

这里有个细节,Ginkgo 虽然并行执行测试用例,但其输出的日志和测试报告格式,仍然是整齐不错乱的,这是如何做到的呢?原来,通过源码会发现,ginkgo CLI 工具在并行跑用例时,其内部会起一个监听随机端口的本地服务器,来做不同进程之间的消息同步,以及日志和报告的聚合工作,是不是很巧妙?

其他的一些 Tips

Ginkgo 框架的功能非常强大,对常见测试场景的都有比较好的支持,即使是一些略显复杂的场景,比如:

  • 在平时的代码中,我们经常会看到需要做异步处理的测试用例。但是这块的逻辑如果处理不好,用例可能会因为死锁或者未设置超时时间而异常卡住,非常的恼人。好在 Ginkgo 专门提供了原生的异步支持,能大大降低此类问题的风险。类似用法:

    It("should post to the channel, eventually", func(done Done) {
    c := make(chan string, 0)
    go DoSomething(c)
    Expect(<-c).To(ContainSubstring("Done!"))
    close(done)
    }, 0.2)
  • 针对分布式系统,我们在验收一些场景时,可能需要等待一段时间,目标结果才生效。而这个时间会因为不同集群负载而有所不同。所以简单的硬编码来 sleep 一个固定时间,很明显不合适。这种场景下若是使用 Ginkgo 对应的 matcher 库GomegaEventually功能就非常的贴切,在大大提升用例稳定性的同时,最大可能的减少无用的等待时间。

  • 笔者一直认为,自动化测试用例不应该仅仅是 QA 手中的工具,而应该尽可能多的作为业务验收服务,输出到 CICD,灰度验证,线上验收等尽可能多的场景,以服务于整个业务线。同样利用 Ginkgo 我们可以很容易做到这一点:

    • CICD: 在定义 suite 时,使用RunSpecWithDefaultReporters方法,可以让测试结果既输出到 stdout,还可以输出一份 Junit 格式的报告。这样就可以通过类似 Jenkins 的工具方便的呈现测试结果,而不用任何其他的额外操作。
    • TaaS(Test as a Service): 通过ginkgo build或者原生的go test -c命令,可以方便的将测试用例,编译成 package.test 的二进制文件。如此的话,我们就可以方便的进行测试服务分发。典型的,如交付给 SRE 同学,辅助其应对线上灰度场景下的测试验收。所以在测试用例的组织上,这里有个小建议,过往我会看到有同学会习惯一个目录就定义一个 suite 文件,这样编译出的二进制文件就非常多,不利于分发。所以建议不要定义太多的 suite,可以一条产品就一个 suite 入口,其他的用例包通过_导入进来。比如:

另外,值得说道的是,Ginkgo 框架在提供强大功能和灵活性的同时,有些地方也需要使用者特别留心:

  • DescribeTable功能是对 TableDriven 模式的友好支持,但它的原理是通过Entry在用例执行之前,通过反射机制来自动生成It方法,所以如果期望类似BeforeEach+It的原生组合来使用BeforeEach+Entry的话,可能在值类型的变量传递上,会不符合预期。其实,相较于DescribeTable+Entry的模式,我个人更倾向于通过方法+多个It的原生组合来写用例,虽然代码量显得有点多,但是用例表达的逻辑主题会更清晰,可读性较高。类似如下:
  • Ginkgo CLI 的 focus 和 skip 命令非常好用,能够灵活的指定想执行或者排除的测试用例。不过要注意的是,focus 和 skip 传入的是正则表达式,而适配这个正则的,是组成用例的所有的 Container 标题的组合(Suite+Describe+Context+It), 这些标题从外到里拼接成的完整字符串,所以使用时当注意。

都有谁在用 Ginkgo?

Ginkgo 的官方文档非常详细,非常利于使用。另外,我们看到著名的容器云项目Kubernetes也是使用 Ginkgo 框架来编写其 e2e 测试用例。

最后,如果您也使用 Go 语言来编写测试用例,不妨尝试下 Ginkgo。