不要再偷懶，請測試你的軟件（借力Docker）

在 DockerCon EU 2015大會 上， Laura Frank 作了題為“ 不要再偷懶，請測試你的軟件 ”的演講。Frank指出，不管公司規模大小，也不管公司處于什么階段，軟件測試都至關重要，而將 Docker 引入開發流程有助于提高編寫和運行測試框架的效率，使組織能夠始終如一地向客戶提供高質量的軟件產品。

Frank是一名來自 Codeship 的資深軟件工程師。他在演講開始時說，軟件測試自首臺用于計算的機器出現時就已經開始了。有位女士為第一臺通用電子計算機 ENIAC 編寫了程序，用于幫助美國陸軍彈道研究實驗室計算炮兵射擊軌跡。她會定期拿一份已知正確的、手工計算的表格檢查計算結果。Frank指出，與其他技術（如結對編程、版本控制、代碼審查和高可用架構）一樣，測試對交付“可用于生產環境的軟件”而言至關重要。

測試的目的包括升級應用程序并避免引入回歸缺陷，驗證更新的功能，證明重構沒有破壞現有的功能。編寫測試和測試套件本地運行耗時過長，正常開發流程受到干擾，測試環境難以正確配置，這些往往會讓人沮喪。Frank提出，將 Linux容器 和 Docker工具箱 引入測試創建和執行過程可以部分地緩解這種沮喪。

Docker Compose 使用戶很容易就可以創建一致的、可重現的容器化環境。Frank表示，許多軟件開發人員都使用Docker Compose創建本地開發環境，但卻沒有將其用于軟件測試。在測試中使用Docker同在開發中使用Docker有同樣的好處，如創建可預測、可重現的環境，這對質量保證過程非常有益。

Frank提醒說，在將Docker Compose用于測試時，可能需要對其工作流做一些修改，甚至需要使用一個不同的Dockerfile指定不同的環境變量和運行目標，Docker Compose通過“ docerfile ”屬性提供這種支持。當容器、應用程序和存儲配置復雜時，要注意避免初始化和執行競態條件。

Docker Compose的docker-compose up命令可以用于執行一個編入Compose YAML配置文件 的自動化測試套件，也可以使用Compose的 run 命令一次運行一個服務，比如：

$ docker-compose up
$ docker-compose run -e “RAILS_ENV=test” app rake db:setup
$ docker-compose run -e “RAILS_ENV=test” app test-command path/to/spec.rb

Frank提到，持續集成與測試相輔相成，依賴CI/CD而測試覆蓋率不足通常會出問題——與在生產環境中發現缺陷相比，開發人員更愿意看到持續交付管道運行失敗。

需要注意的是，運行測試的環境與生產環境差別越小越好。Frank認為， 如果應用程序將來會運行在容器中（并且在容器中開發），那么構建管道中的測試也就必須在容器中進行。為此，開發人員可能會傾向于運行“Docker- in-Docker”。Frank指出，任何考慮這樣做的人都應該讀下 Jér?me Petazzoni 的著作，比如文章“ 將Docker-in-Docker用于CI或測試環境？請三思而行 ”。

Frank認為，在開發過程中使用容器時，很容易錯誤地將容器看作一個運行特定負載的“小型虛擬機”。然而，如果能更準確地將容器視為簡單OS進程，那么測試過程就可以獲得額外的好處。例如，需要在容器化應用程序上運行的多個測試可以并發執行。在DockerCon歐洲大會質量改進主題的基礎上，Frank提出，可以增加一個并發構建管道，當質量下降時（比如測試代碼覆蓋率降到一定水平之下， linting 錯誤增加，或者違反 ratchets 中的規則），使構建失敗，以此保證軟件的質量。

Frank引用 Edsger Dijkstra 的話對演講進行了總結。他表示，雖然測試至關重要，但它并不能保證開發出的軟件沒有缺陷，應該恰當設定測試預期。

讀者可以從SlideShare上下載Frank演講用的 幻燈片 ，演講視頻稍后將在 Docker 油Tube 上提供。

查看英文原文: Stop Being Lazy, and Test Your Software (with the Help of Docker)