我正在看一個現在有單元測試和集成測試（使用BDD）的項目。我應該爲每個功能編寫多少個集成測試（或場景）？
集成測試爲每個測試使用一個值文件。 （鑑於幾乎所有的數據集都是無限排列的。）我試圖弄清楚這是否可行，爲什麼。 （我對「測試」非常陌生）
我是否正確地說這些集成測試是爲了測試數據在組件中是否正確流動，所以可以只有一組值？
而且數據的「排列」應該在單元測試中測試嗎？那麼我們知道各個單位可以處理不同的數據。
還是我完全錯過了一個把戲？
實際上，只測試一組數據是非常少的。可能這只是一個好天氣行爲的場景。
我也建議添加惡劣的天氣行爲。
關於排列組合：這很容易失控。因此，谷歌在MC/DC覆蓋：修改後的條件決策覆蓋。它減少了所有可能性的最大數量，同時在該角度仍然具有相同的覆蓋範圍。
在BDD集成測試有兩個目的：
你寫集成測試，測試驅動器（強迫你來實現，以使測試通過）應用程序的行爲的主要領域。集成測試是一種規範，是開發人員和利益相關者之間以及開發人員和未來開發人員之間溝通的一種手段。其次，集成測試按照你所說的做：他們測試單元測試組件之間的每個交互是否正確。
如果你開發測試第一，你通常會發現，試駕激勵所有你需要的集成測試的，但如果你測試之前編寫一些代碼，你可能需要回去寫更多的集成測試所以你有足夠的整合覆蓋。在這種情況下，您應該嘗試對您編寫該代碼的業務原因進行逆向工程，並在集成測試中對其進行表達，從而爲業務帶來價值。
對於給定的集成測試，「一組值」是否足夠取決於每個可能的一組值的商業含義。例如，如果你正在處理的支票，你可能要三個集成測試：
您會使用單元測試來驅動這些場景中的微小變化，例如，不同的錯誤情況（支票上的金額爲零，其中一個數字難以辨認，另一個數據不在右邊的數據庫中），這些都會導致屏幕上顯示錯誤。
上下文：「整合測試」在不同的環境下意味着不同的事物，但我隨着您的術語而行。我想通過「集成測試」你的意思就像黃瓜場景，強調它是一個規範而不是技術細節的測試如何工作。
「可以只有一組值」，這取決於所討論的軟件;不可能有普遍的答案。 – Raedwald