前一節中我說過，有時候測試的內容與你想象的完全不同。更讓人操心的是，有時它們根本什麼都沒測試。
我的乙個同事習慣於稱這種測試為快樂的測試，指某個測試快樂地執行一段生產**——或許是全部的執行路徑——卻沒有一句斷言。是的，你的測試覆蓋率報告看起來很棒，因為測試全面地執行了你寫的每句話。問題是這種測試只有在生產**丟擲異常時才會失敗。
你無法依靠這種測試來保護自己，對嗎？特別是如果程式設計師慣於將所有測試方法體封裝到try-catch塊中的時候。**清單2.2展示了這種壞習慣。
某些測試相對來說不太容易失敗，**清單2.2是乙個典型的極端例子，其中的測試或許永遠不會失敗（過去也沒有過）。如果你仔細觀察，你會注意到即使add（-1）沒有如期地丟擲異常，測試也不會失敗。
幾乎不會失敗的測試就等於廢物。也就是說，間歇性地通過或失敗的測試就是在公然地侵害程式設計師小夥伴們，見圖2.3。
構建有效的單元測試
以下內容翻譯自google官方文件 building effective unit tests 水平有限自己感覺很多內容翻譯並不到位，但找不到更好的表達方式，如果您覺著有更好的表達方式，幫助我改進！注意 單元測試不適合測試複雜的ui互動事件。如果想這麼做，你應該使用ui測試框架，這將會在 autom...
單元測試（一）
coding utf 8 驗證乙個序列的單元測試 import unittest import random class testsequencefunctions unittest.testcase def setup self 初始化乙個遞增序列 self.seq range 10 print ...
單元測試 單元測試編寫的原則
公司要求提公升單元測試的質量，其中我作為方案和推動的主導，對開發過程中的單元測試，有了一些思考和總結 單元測試編寫的目的，是面向計算機特性的，基於函式的in out，所以單元測試的好幫手就是斷言，通過不斷的構造輸出並對結果進行斷言，我們就可以針對乙個物件以及它的函式，構建出充足的用例去包裹它，以期望...