在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

欢迎扫描二维码关注公众号，天天都给你推送新鲜的前端技术文章