單元測試有沒有這樣的事情？

Question

鑑於您不能編寫動態內容的測試，除此之外，是否有任何理由不應添加單元測試？也許測試項目的完整性可能被認爲沒有必要，但我可以用這兩種方式來辯論。

例子：

的Objective-C/Xcode的=編寫一個測試，以確保字體列在您的常量在項目的info.plist UIAppFonts陣列也列出。

Answer 1

從技術上講，測試都應該堅持的幾個關鍵指標：他們應該是速度快，易於閱讀和理解，一致的​​結果，等

如果任何一個好單位的這些（及以上）的品質測試沒有得到滿足，你會以成本結束。如果單元測試很慢，那麼你花費時間來扭動你的拇指，或者如果它們太硬，你會花費時間來解釋測試，而不是編寫新的/代碼，對於結果不一致的測試也是如此。

因此我們可以說壞單元測試存在。

但是，如果我們看一下「我們應該測試X」的具體例子，那麼這就更加主觀。

如果像getter/setter（又名：簡單代碼）那樣容易測試，那麼有些人可能不會覺得值得他們的時間，而另一些人認爲它沒有問題：通過添加這些快速，小測試，你永遠不會遇到意外只是因爲有人在他們的getter/setter中添加了邏輯，並且沒有任何測試來發現任何錯誤。

我對Objective-C沒有任何瞭解，但乍一看似乎是一個合理的測試概念。

一般規則：除非你有明確的理由而不是來測試一下，測試一下。

Answer 2

單元測試實際上只是一個工具，可以爲您的代碼質量創建較低的水印。

如果您100％確信自己的代碼能夠按預期工作，那麼您就有足夠的單元測試。在這種情況下添加更多的測試只是浪費時間。

認爲「你好世界」。你會爲此寫多少個單元測試？ 1還是0？

如果你不確定某件事情，那麼你需要更多的單元測試。這種感覺的原因可以是：

1. 你或其他人只是發現了一個錯誤。總是爲錯誤編寫單元測試。
2. 有人要求提供一項新功能，但您不確定如何實施 - >編寫測試來設計API，並確保最終結果符合預期（並確保每個人都知道並同意預期） 。
3. 您正在使用新技術並希望記錄a）它如何工作以及b）您如何使用它。當你後來想知道「我是如何做到這一點的？」這些測試作爲一種模板工作。
4. 您剛剛在使用的庫中發現了一個錯誤。當你修復這個bug時，你還應該添加一個測試用例，告訴你「這個bug現在已經修復了！」所以你以後不會在錯誤的地方打獵。
壞單元測試

例子：一個單元測試

測試getter和setter方法

殘疾人單元測試的內部

1. 集成測試躲在
2. 註釋掉單元測試
3. 單位每天或每週打破一次的測試（它們削弱了你的信心，並且願意編寫單元測試）
4. 任何需要執行10秒以上的測試
5. 超過50行的單元測試所有的設置代碼）

Answer 3

我的答案是肯定的，編寫測試仍然是編寫代碼，避免錯誤的最佳方法是不要將代碼寫在第一位。

恕我直言，編寫好的測試通常比編寫好的代碼更困難。除非您瞭解問題，否則無法編寫可用的測試，無論它應該如何工作以及它如何失敗。前者通常比後者更容易理解。

說了這麼多，你必須從某個地方開始，有時候最簡單的測試就是先寫最簡單的測試，即使那時候真的沒有測試任何有用的東西。 但是，在您完成TDD過程時，您應該將這些測試展開。努力建立一個僅記錄對象外部接口的測試集。這很重要，因爲當您回到對象以供稍後重構時，您需要一組測試來定義對象對程序其餘部分的責任，而不是對象本身的責任。

（也就是說，您希望將對象的輸入和輸出作爲「黑盒」來測試，而不是對象的內部接線。這樣可以更自由地改變W/O，從而導致對象外部的損壞。 ）