測試不是全部，但最重要

最近我一直在思考的一個話題是加里·伯恩哈特所謂的“ 意識形態”。如果你願意，我強烈建議你現在就去看看，我會在這裡等。另外，這裡是文章的摘要：動態類型愛好者喜歡說他們不需要編譯器，因為他們有測試; 靜態類型愛好者喜歡說他們不需要測試，因為他們有編譯器。

就我的經驗而言，前者說法比後者更普遍常見，很少聽到喜歡靜態類型的人說他們不需要進行單元測試。也許在過去，情況有所不同; 在歷史的某個時刻，谷歌工程師聲稱單元測試只對糟糕的程序員來說才是必要的，他們已被證明是錯誤的，現在谷歌嚴肅地執行所有代碼的測試。

我有時聽到Node.js，Python或Ruby等語言愛好者說，他們並不真正需要編譯器提供的安全性和結構，因為他們有單元測試套件來捕獲bug。

這是一種有害的哲學。在某些情況下，當錯誤並不重要時，這並不會很糟糕：在早期創業公司中，錯誤的影響有限，因為您根本沒有客戶，或者客戶可以容忍問題。此外，你能負擔得起漏洞，因為快速升級和改變產品的利潤超過了修補bug的成本。

不幸的是，隨著初創公司的發展，這種情況會發生變化，而錯誤的代碼和迴歸錯誤會直接導致客戶流失。這很複雜，因為隨著軟件複雜性的增加和團隊規模的擴大，造成錯誤的可能性會迅速增加。除非你對此採取行動，否則團隊最終只是在滅火而不是製造產品的位置。

“但如果你有一個好的測試套件，這不會發生！” 很多開發者這樣聲稱。如果測試不夠好，他們在能找出我的錯誤嗎？錯誤有很多方式可以通過測試，這裡有一些例子。我在專業環境中遇到過其中的每一種，包括有非常嚴格的編碼標準的Google：

• 沒有測試任何東西的測試。測試可以執行代碼並獲得100％的代碼覆蓋率，但如果它沒有檢查正確的條件，那麼它不是一個好的測試。

• 沒有人寫過它們。有時當修復某些東西有壓力時，人們會跳過編寫測試的過程。許多公司都有一種關注儘快上市的文化，這不利於編寫可靠的軟件。

• 不檢查重要案例。我曾看到只檢查快樂路徑的測試，沒有檢查任何錯誤的情況 - 如果你無法連接到數據庫，或連接丟失怎麼辦？如果您嘗試閱讀的文件不存在怎麼辦？

• 集成/功能測試。就其性質而言，集成測試更難以編寫和維護，並且輸入的組合以指數方式爆炸，因此在絕對關鍵的項目之外擁有可靠的集成測試套件是非常罕見的。

• 在推送之前沒有人運行測試或查看結果。這種情況發生在沒有任何進程的設置中（我正在看你，啟動黑客），其中失敗的測試會阻止提交/合併/推送。

這裡有一些解決方案。有些非常容易和普遍：代碼審查，持續集成，預先掛鉤和主分支上的嚴格權限只是少數幾個。

一個減少很多麻煩的更深層次的解決方案是使用某種類型的提示。我推薦這個的原因是，如果你一直使用它，它會從等式中消除很多人為錯誤 - 編譯器將始終記得檢查所有內容，即使是最好的人類偶爾會滑倒並忘記某些東西。編譯器在查找錯誤方面也要快得多，運行集成測試套件可能需要很長時間 - 根據經驗，我不會阻止集成測試的提交，否則可能需要數小時才能進行更改。它也是自動的：你不必編寫測試。在我的書中，少工作是一件好事。

但是，我是否必須使用其中一種令人煩惱的語言（如C ++或Java）來實現這一點？花所有時間來嘗試滿足編譯器而不是真正的工作？不！您可以在帶有TypeScript或Google的Closure編譯器的Node.js中使用它，在Python中您可以使用Python 3的類型聲明，而在Ruby中您可以使用類似RDL（免責聲明，我從未使用過它）。還有現代靜態類型的語言，如Go，Rust，Swift和Kotlin，它們比前幾代使用起來更舒適。

對於不同系統之間的通信，您可以將JSON與JSON Schema或Protocol Buffers一起使用（如果需要，可以將其序列化為JSON）。過去有個恐怖故事：我的團隊正在使用Node.js和Python構建分佈式系統，系統中的不同節點將通過JSON傳遞消息。有人對一個系統進行了更改，改變了其中一個消息中字段的類型，但在實際嘗試訪問該字段之前有幾個躍點。嘗試訪問它的系統顯然已經崩潰，並且追蹤該字段被修改的位置需要相當多的偵探工作（除了導致生產中斷）。

幸運的是，崩潰發生在Python系統中，所以我們有一個KeyError和堆棧跟蹤，至少知道發生了什麼，如果它發生在一個Node.js系統中它會產生undefined並能繼續運行。如果我們對消息使用了某種類型的檢查，那麼這個調試練習就會簡單得多。

我強烈建議，如果您正在進行任何類型的後端或基礎架構開發，並且您尚未使用上面提到的測試方法，那麼您該開始使用了。它會在以後為您節省一些麻煩。

閱讀更多 Python部落 的文章

關鍵字: 軟件 Rub 愛好者