我把測試當做是文檔。這是我對代碼預期效果的文檔。測試告訴我，我(或我之前的人)如何期望代碼來工作，以及他們認為事情會出錯的地方。所以，當我現在編寫測試時，我會記住這一點：

演示如何使用我正在測試的類/函數/系統。

展示出所有我認為可能會出錯的內容。

上述的一個必然結果是，在大多數情況下，我測試的是行為，而不是實現。

我在#2中漏掉的東西就是bug的來源。

因此，每當我發現一個bug時，我都會確保代碼修復程序有相應的測試(稱為回歸測試)來記錄信息：這是另一種可能出錯的方法。

但是，僅僅編寫這些測試并不能提高代碼質量，需要實際編寫代碼。但是我從閱讀測試中獲得的見解能幫助我寫更好的代碼。

但是，這不是唯一一種要做的測試。接下來就是部署環境登場的地方。

對于經過良好測試的代碼也是如此：如果你的機器上沒有所需的庫，則會崩潰。

首先是你用來開發的機器(所有“它在我的機器上能正常工作!”這類meme(梗)的來源)。

其次是你用來測試的機器(可能與你用來開發的機器相同)。

最后，有你用來部署的機器(請不要讓它與你用來開發的機器相同)

如果測試和部署機器之間的環境不匹配，你就麻煩了。這就是部署環境的用武之地。

我們的機器上有本地開發，它位于docker中。

我們有一個開發環境，其中機器安裝了一組庫(和開發工具)，我們在上面安裝在這些庫上編寫的代碼。其他依賴系統的所有測試都可以在這里進行。

然后是beta / stage環境，它與生產環境完全一樣。

最后，生產環境，它們是運行代碼并為實際客戶提供服務的機器。

目的是嘗試捕獲單元和系統測試發現不了的bug。例如，請求和響應系統之間的API不匹配。

我想個人項目或小公司的情況會有很大不同。并非每個人都有資源來部署自己的基礎設施。但是，這個想法對于AWS和Azure等云提供商的服務也適用。

你可以為開發和生產設置單獨的集群。AWS ECS使用docker鏡像進行部署，因此各環境之間相對一致。棘手的一點是其他AWS服務之間的集成。你是否從正確的環境中調用了正確的端點?

你甚至可以更進一步：為其他AWS服務下載備用容器映像，并使用docker-compose設置本地完整環境。這樣能加速反饋循環。

好啦！今天的分享到這里就結束了，希望大家持續關注馬哥教育官網，每天都會有大量優質內容與大家分享！

版權聲明：轉載文章來自公開網絡，版權歸作者本人所有，推送文章除非無法確認，我們都會注明作者和來源。如果出處有誤或侵犯到原作者權益，請與我們聯系刪除或授權事宜。