我看到許多問題詢問“如何”以特定語言進行單元測試，但沒有問題詢問“什么”，“為什么”和“何時”。它是什么？它對我有什么作用？我為什么要使用它？我什么時候應該使用它？有哪些常見的陷阱和誤解
2 回答
江戶川亂折騰
TA貢獻1851條經驗 獲得超5個贊
粗略地說，單元測試是與測試代碼隔離地測試代碼的各個部分。我想到的直接好處是：
運行測試變得自動化且可重復
與通過GUI進行點擊測試相比，您可以進行更精細的測試
請注意，如果您的測試代碼寫入文件，打開數據庫連接或通過網絡執行某些操作，則將其更恰當地歸類為集成測試。集成測試是一件好事，但不要與單元測試相混淆。單元測試代碼應該簡短，優美且易于執行。
查看單元測試的另一種方法是先編寫測試。這就是所謂的測試驅動開發（TDD）。TDD具有其他優勢：
您無需編寫推測性的“將來可能會需要”代碼，僅足以使測試通過
您編寫的代碼始終包含在測試中
通過首先編寫測試，您不得不考慮如何調用代碼，從長遠來看，這通?？梢愿纳拼a的設計。
如果您現在不進行單元測試，建議您開始使用它。獲得一本好書，幾乎任何xUnit-book都可以做，因為這些概念之間可以很容易地轉移。
有時編寫單元測試會很痛苦。當這種方式得到解決時，請嘗試尋找可以幫助您的人，并抵制“只寫該死的代碼”的誘惑。單元測試很像洗碗。它并不總是那么令人愉快，但是可以使您的隱喻廚房保持清潔，并且您真的希望它保持清潔。:)
編輯：盡管我不確定這是否如此普遍，但我想到了一個誤解。我聽說一個項目經理說，單元測試使團隊將所有代碼編寫兩次。如果看起來和感覺是那樣，那么，您做錯了。編寫測試不僅通?？梢约涌扉_發速度，而且還為您提供了一個方便的“現在我已經完成”的指示符，而您本來可以沒有這些。
ITMISS
TA貢獻1871條經驗 獲得超8個贊
我不同意Dan（盡管更好的選擇可能只是不回答）...但是...
單元測試是編寫代碼以測試系統行為和功能的過程。
顯然，測試可以提高代碼的質量，但這只是單元測試的膚淺優勢。真正的好處是：
在確保不更改行為（重構）的同時，更輕松地更改技術實現?？梢詫涍^正確單元測試的代碼進行積極的重構/清理，而幾乎不會在不注意的情況下破壞任何內容。
在添加行為或進行修復時使開發人員充滿信心。
記錄您的代碼
指示代碼中緊密耦合的區域。很難對緊密耦合的代碼進行單元測試
提供一種使用您的API并盡早發現困難的方法
指示不太緊密的方法和類
您應該進行單元測試，因為這樣做符合您的利益，可以為客戶提供可維護的優質產品。
我建議您將其用于對現實行為進行建模的任何系統或系統的一部分。換句話說，它特別適合于企業發展。我不會將其用于一次性/實用程序。我不會將其用于測試有問題的系統部分（UI是一個常見示例，但并非總是如此）
最大的陷阱是開發人員測試的單元太大，或者他們將方法視為單元。如果您不了解控制反轉，則尤其如此-在這種情況下，單元測試將始終轉變為端到端集成測試。單元測試應該測試個體行為-大多數方法都有許多行為。
最大的誤解是程序員不應進行測試。只有糟糕或懶惰的程序員才會相信這一點。蓋屋頂的家伙不應該測試嗎？更換心臟瓣膜的醫生是否應該不測試新瓣膜？只有程序員才能測試他的代碼是否達到了他的預期目標（QA可以測試極端情況-告訴人們要做程序員不希望的事情時代碼的行為，客戶可以進行驗收測試-代碼可以做到嗎客戶為此支付了什么費用）
蠱毒傳說
TA貢獻1895條經驗 獲得超3個贊
與“只是打開一個新項目并測試此特定代碼”相反，單元測試的主要區別在于它是自動化的，因此可重復。
如果您手動測試代碼，則可能會說服您代碼在當前狀態下運行良好。但是大約一周后，如果您對其進行了一些修改，該怎么辦？您是否愿意在代碼中有任何更改時手動重新進行測試？可能不是:-(
但是，如果您可以在幾秒鐘之內隨時以完全相同的方式單擊一次測試，則只要出現問題，它們就會立即向您顯示。而且，如果您還將單元測試集成到自動化的構建過程中，即使在看似完全不相關的更改在代碼庫的遙遠部分中破壞了某些內容的情況下，它們也將提醒您注意錯誤-當您什至不會想到需要重新測試該特定功能。
這是單元測試相對于手工測試的主要優勢。但是，等等，還有更多：
單元測試極大地縮短了開發反饋循環：如果使用單獨的測試部門，您可能要花幾周的時間才能知道代碼中存在錯誤，而此時您已經忘記了大部分上下文，因此可能要花幾個小時才能完成查找并修復錯誤；OTOH帶有單元測試，反饋周期以秒為單位，并且錯誤修復過程通常遵循“哦，我* t，我忘了在這里檢查這種情況”的意思：-)
單元測試有效地記錄（對您的理解）代碼的行為
單元測試迫使您重新評估設計選擇，從而使設計更簡單，更簡潔
反過來，單元測試框架使您可以輕松編寫和運行測試。
- 2 回答
- 0 關注
- 694 瀏覽
添加回答
舉報
0/150
提交
取消