我已經開始使用Quick和Nimble編寫iOS的第一個BDD測試，並且我有一個關於測試覆蓋率的問題。BDD和測試覆蓋率
我意識到，在傳統的單元測試中，開發人員的目標是擁有100％的測試覆蓋率。不過，我還沒有讀過BDD。如果我正確理解BDD，當我測試我的代碼的行爲時，那麼實現的細節並不重要;重要的是，我從我的代碼中獲得預期的結果，對嗎？
我開始試圖獲得100％的代碼覆蓋率，但它似乎開始寫脆性測試，因爲不是專注於我的代碼的結果，而是試圖覆蓋我的代碼可以採用的所有路徑。
正如評論之一提到的，BDD的核心方面是給你測試（可能是自動的）是保證你的產品是做正是什麼是應該做的。顯然：「不低於」。
在這個意義上，BDD 加覆蓋率可以幫助你確保你的產品是不是做更比。
換句話說：假設你所有的BDD測試都通過了;並且你的覆蓋率是75％...... 可能是意思是：你的代碼庫的25％是不需要爲了提供你的BDD測試用例中指定的行爲。意思是：你可以仔細看看這些25％的未觸及線條，以瞭解爲什麼它們不是必需的;然後確定是否有機會刪除未使用的源代碼的相同部分。
如：第二好的東西您可以做軟件開發人員：從您的代碼庫中刪除代碼，而不會降低產品的功能。
（及備案：在最好的事情，一個SW開發者可以做：添加新的功能，以他的產品，吸引新客戶 - 刪除代碼有助於從長遠來看你的質量，但客戶支付你的薪水短，中期和長期）
這是有道理的。 –
當你討論75％vs 25％時，我發現更清晰。原因在於我在一些'guard'語句中添加'fatalError（）'以幫助我輕鬆地找到邏輯中的漏洞。然而，當運行我的測試時，'guard'語句的'else'子句不會被執行，因爲事情正如預期那樣運行。我正在創建額外的測試，以使'guard'語句落入'else'子句，因此覆蓋了'else'子句，不知道是否適合實現100％的覆蓋率。 –
BDD和TDD的區別並不在於測試覆蓋面，而是關注軟件中的行爲而不是測試實現細節（測試API而不是實現，有人稱之爲）， BDD和TDD都將導致100％的代碼覆蓋率，因爲其中一個主要想法是在任何實現代碼之前先編寫測試。 –
您可以同時擁有100％的測試覆蓋率，但BDD將確保您開發出正確的產品。 –
「我意識到，在傳統的單元測試中，開發人員的目標是擁有100％的測試覆蓋率」。他們當然不會。 100％的測試覆蓋率意味着代碼的所有分支至少被遍歷一次，如覆蓋工具所證明的那樣。這通常是不必要的，除非你正在編寫高度保密的代碼（正式的方法可能更合適）。一個單元意味着要測試一個單元的正確功能，以便在錯誤修復和重構後，可以輕鬆檢查功能是否正確。如果打算覆蓋100％，那麼也必須重寫單元測試。 –