寫好單元測試的10個技巧

最新 06-15

作者 Grzegorz Ziemoński

翻譯袁思思

來源 https://dzone.com/articles/10-tips-to-writing-good-unit-tests

自從我們在之前的文章中開始做單元測試，我覺得我們可以繼續做這個主題，並且展示一些寫得好的、可維護的單元測試的規則。這個選擇很隨意，而且絕不是完整的，但是我希望它能夠對你有所幫助。那我們就開始吧！

使它們簡短

因為我們正在測試一個單獨功能的一部分，通過一個單獨代碼單元交付，一個測試需要合理的簡短是有意義的。如何簡短？取決於多種因素，但是通常不會超過幾行代碼。

不要重複自己

組合好過繼承

一旦你承認之前的兩點，你也許就會禁不住給你的測試創建一些base class，它將包含常用的代碼。如果你這麼做了，現在就停下！這樣一個base class工作像是一個磁鐵，可以用於各種不相關的共享代碼，並且快速成長，直到它接管你的項目，你的公司，甚至你的狗。保護好你的狗，使用組合方法。

快

單元測試是一些你可能幾乎一直運行的東西。由於這個原因，確保移除外部相關項和一些讓你測試變慢的其他東西。這些東西通常像是資料庫，外部系統或文件操作。同時別做過頭——測試單元的完整隔離也不是一個好的解決方案（https://dzone.com/articles/unit-testing-the-myth-of-complete-isolation）。

100%的確定

每次我聽到有些人已經完成95%的工作測試套件，就足夠好可以去生產了，我就既想笑又想哭。為了老天（或你的狗），單元測試應該100%的完成。只有100%通過的測試，才意味著所有都ok了（有了這些單元，你還需要其他類型的測試）。如果你的單元測試看上去單薄，確保發現根本原因並且儘快修復它。

不要忽視測試

上面的第四第五點，特別重要的是，在測試中添加忽略注釋並不是修複測試套件的方法（https://dzone.com/articles/open-letter-from-an-ignored-test）。這是一種讓你的測試套件更加不可靠的方法，因為現在它沒有從回歸錯誤等等其他錯誤中保護你了。

測試你的測試

是的，你沒看錯，而且我也沒瘋。我不是說給你的測試寫測試。我是說像是變異測試，測試驅動開發，或者在你的代碼庫中頻繁的「改變隨機內容」的實踐來看看是否有測試失敗。我也常常做一些訓練，試著對代碼做出一些潛在改變，而我的測試不會發現這些改變。

給測試取個好名字

ThrowException不是一個好的測試名字。儘管我不確信每個項目都應該為測試用一些花哨的命名慣例，但我完全確信你能夠通過閱讀失敗測試用例的名字來判斷代碼的哪一部分被破壞了。

每個測試都有個邏輯斷言

為了實現能夠通過閱讀失敗測試的名字來判斷哪錯了的美好目標，需要的不僅僅是好名字，還需要更多的東西。一個測試檢查的許多東西也必須是限定的。因此，一個好的單元測試應該只包含一個邏輯斷言，即只檢查測試方法的一個輸出/副作用。

設計測試

這是一個meta-tip，在這篇文章中貫穿所有其他技巧，而且那些我在這裡沒有提到的技巧。對待你的測試代碼要像你對待你的生產代碼那樣同樣關心。考慮好的設計原則和指標，像是在測試代碼和生產代碼之間低耦合與代碼異味，諸如重複、無用代碼等等。記住，一個好的測試套件通過在變更和重構代碼時讓你感到安全，可以讓你的生活更加容易，然而一個壞的測試套件讓你悲慘，浪費大量時間和讓你的代碼幾乎無法變更。