乐趣区

在Shell中进行独立的集成测试

翻译:疯狂的技术宅原文:https://zachholman.com/posts/…

本文首发微信公众号:jingchengyideng 欢迎关注,每天都给你推送新鲜的前端技术文章

我在开发 during.com 时创建了一系列的微服务,它们被用来做一些同步、导入和单调繁重数据处理之类的工作。
如果你对微服务不熟悉,那么它只是一个花哨的名词而已,意思就是“让我们把这些该死的业务逻辑散落的到处都是!”
不管怎样,我的微服务到处都是,嗯,的确是“微”。不过我绝对不是一个逗逼,我已经多次重写了自己的 web 服务,从 Rails 中的一个目录开始,然后迁移到 Ruby,接着是 Crystal,之后是 Go,现在又回到了 Ruby。这并不是在浪费时间,这只是为了以防万一而尝试新的方法。
最后我又把这些服务迁移回了 Ruby。这段时间 Ruby 的表现真是没得说,它能很轻松的进行扩展来应对用户的请求。不过目前这个应用还没有进入 beta 测试阶段,在你还没有用户的时候,它的确容易扩展。实际上如果在没有用户使用的前提下,几乎任何关于软件开发的一切问题都不算什么,当然除了赚钱(当然了这也并没有成为硅谷任何一家公司的障碍)。
好吧我跑题了,我一直都很享受用 Shell 来测试这些服务的过程。
在 POSIX shell 环境下测试, 或者 UBIQUITOUSIX shell 环境也可以
我已经用 Shell 脚本为这些服务编写了测试,很不错。首先,不需要为基本环境操心。无论是我的 AWS 实例,还是我的持续集成服务器,还有我自己的开发机上都有 Shell 环境。所以不需要安装任何东西,也不必运行什么 Docker 实例(实际上用它肯定也没什么坏处)。
不过最重要的一点是,我的测试是独立的,独立于将来可能会使用的任何语言。我可以在不同的语言和框架之间进行切换,而不需要对测试脚本做任何改变。这一点非常重要,因为如果你的 v1 版本中有一个微妙的 bug,而测试却通过了,当你开始重写 v2 版本的服务时,如果在无意中修正了这个 bug,测试将可能失败。这意味着你暴露给其它服务的 API 不会因此而意外中断,你可以使用其它服务来暂时顶替,为修复 bug 争取时间,而不是在部署到生产环境后大吃一惊。
这些测试的工具也是相当不错的,这些年我一直在用我的好友 Blake Mizerany 写的一个 Shell 环境下的小工具 roundup。最近我一直在使用 Sam Stephenson 的 bats,现在它已经形成了一个十分活跃的社区(哈,谁能想到呢,仅仅是一个 shell 测试工具而已)。我的 Shell 测试看起来就像这样,用 bats:
@test “Responds with events within the given timespan” {
url_params=”?starts_at=2017-05-01T00:00:00-00:00&ends_at=2017-05-31T00:00:00-00:00″
run curl “$URL$url_params” –silent -H “Authorization: Bearer:$bearer”

assert_output –partial “Test Event 0”
assert_output –partial “Test Event 2”
refute_output –partial “Test Event 5”
refute_output –partial “No location data”
refute_output –partial “Not included in the date span”
}
测试非常简单,也容易理解。基本上就是运行 curl 然后检查输出结果,完成。
整合周围的一切
最后一点,这些微服务非常之小,我完全可以不用为它们写任何其它的测试,只需要写集成测试即可。全栈测试(full-stack)真的非常有趣,但是人们对此很谨慎,不知道它会成为下一个好主意还是成为世界上最差劲的想法。对于它的价值,GitHub 的主旨是随时愉快地运行在零单元测试的生产环境下。总的来说我正在实践这种悬而未决的理论,不过我会悬崖勒马。如果你感兴趣的话可以阅读关于这个话题更多的文章。
但是我要说的是在这种情况下,哇,一股新鲜空气袭来。我们的测试是可移植的,如果我重写了服务,不必为它们重写新的测试。我只需要通过自己的基于 shell 的测试即可。

本文首发微信公众号:jingchengyideng
欢迎扫描二维码关注公众号,每天都给你推送新鲜的前端技术文章

退出移动版