在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

歡迎掃描二維碼關注公衆號，天天都給你推送新鮮的前端技術文章