末端2端測試是否足夠？

Question

我的問題主要是關於測試方法。 我正在爲實踐TDD（測試驅動開發）的組織工作。我們使用AngularJS，因此使用了完整的測試堆棧 - Jasmine用於單元測試，Protractor用於e2e測試。

當開發一個功能時，我們的過程首先編寫一個失敗的e2e測試，然後使用TDD編寫功能。測試僅針對公共方法編寫（無論是用於控制器/指令/服務）。 它自身的產品不包含任何複雜的邏輯（除了一些例外）。 最近我們開始討論這樣一個事實，即編寫控制器的單元測試沒有意義，因爲它們暴露了功能，其中100％暴露在視圖中，並且無論如何都使用e2e測試進行測試。基本上 - 單元測試和e2e測試是重疊的。 起初我們都同意，但這個決定打開了一個潘多拉盒子。畢竟，關於指令的事情可以說是一回事。那麼爲什麼要測試它們呢？ 然後服務問題出現了。他們中的大多數人（98％）只是進行後端調用並返回響應。那麼爲什麼不簡單地模擬httpBackend並在測試通過e2e測試的控制器時測試服務。

你得到的漂移....

，我看到的好處做兩個單元測試和端到端的測試，儘管他們幾乎重疊。主要 - 即時反饋和「可執行文件」。 你在練什麼？你是否看到其他好處，並且是「果汁值得擠壓」 - 是否值得爲最簡單的實現編寫重疊測試，以獲得上述兩個好處？

Answer 1

這是一個很大的話題，而不是真的可以有權威的答案，但我會盡我所能涵蓋幾點。

首先，你應該考慮測試的目的。根據Agile Testing Quadrants，單元測試主要是爲了支持團隊。它們通常是寫在接近產品的地方（例如使用TDD，可能由開發人員自己制定），並有助於提高開發人員的信心，即他們沒有因最後的變化而破壞任何東西。有了這種信心，開發人員可以高效地工作，並重構魯莽的abadon - TDD夢想。單元測試並不回答「這是否適合我們客戶的目的」的問題，但這不是他們在那裏的原因。功能測試（e2e，如果我理解你的描述）仍然支持團隊快速轉向測試結果，但實際上開始回答「用戶可以做這件事嗎？」這個問題。您正在測試用戶看到的內容，並開始以對用戶有意義的方式測試您的實際產品。

象限3和4開始解決產品是否執行以及（即它適合用途而不僅僅是功能），但那是另一個主題。

基於對測試的理解，部分答案取決於您的團隊結構。你有獨立的開發和測試團隊嗎？如果是這樣，那麼開發人員可以編寫單元測試（畢竟他們是爲了他們的利益）並且讓測試團隊獨立處理其他象限（包括按照他們認爲合適的方式編寫e2e）。如果你的測試和開發團隊是一樣的？如果您可以從單元測試中得到類似的週轉時間（測試書面 - >有用的結果），您可以從單元測試中獲得類似的週轉時間，將注意力集中在它們並獲得兩種方法的回報而不重疊是有意義的。

我想給出的簡短答案是簡單地問「我們從這個測試中獲得什麼好處？」。如果您發現測試重疊的答案，刪除冗餘可能有意義。

上面的一些要點和其他一些要點here已經討論過了，所以我現在就不再亂了。