如果功能測試滿足，單元測試是否仍然重要？

Question

對於一個簡短的總結：

• 單元測試是規模較小的一個期望的東西做是正確的在開發中的觀點。
• 功能測試是那些希望的事情是正確的用戶視圖

如果功能測試已經滿意，我們是否還需要做單元測試？

很可能（讓我們使用web開發作爲上下文），通過使用瀏覽器通過讓其他用戶/人員嘗試系統/應用程序來查看是否正確，這很常見。

讓我們推出像邊緣情況下的其他測試。

Answer 1

是否有任何指標用於確定功能測試是否「滿意」？

我覺得有一個客觀的測量來創建一個比較測試類型的基線有幫助，一個常見的測試是代碼覆蓋率。

通過識別代碼覆蓋率，很容易比較功能測試和單元測試，功能測試是否覆蓋了與單元測試相同的代碼行？如果是這樣，那就多餘了。

問題是這樣的忽略一噸的其他問題：

• 是功能測試望而卻步長期運行？他們難以設置，還是僅在CI中執行？那麼在單元測試中重複代碼行可能是有意義的，這將爲開發人員提供快速反饋。
• 這是一個POC還是一個不成熟的項目？功能測試可以提供最佳效果，因爲它們應該能夠聲明更高級別的用例並從實現細節中抽象出來。當實現細節不確定時，這非常有用
• 代碼覆蓋率是有誤導性的，一個以IO爲中心的庫（即DB驅動程序）可以通過嘲笑其依賴關係輕鬆實現100％的代碼覆蓋率。如果我們在這種情況下使用代碼覆蓋率來比較功能測試和單元測試，那麼我們會缺少多個測試維度，因爲功能測試將執行IO依賴關係。 （在這種情況下，IMO單元測試實際上是一個非常小的值，並且會給IO重碼帶來虛假的信心，從而導致在dev後期週期通常發現的集成錯誤，修復問題的成本更昂貴
• You touch on邊緣情況下，功能測試通常會說明幾個客戶端流程，使用功能測試來執行所有邊緣案例和錯誤處理通常傾向於浪費資源並最終創建難以維護的巨大套件，並且測試速度很慢