TDD單元測試，集成測試和驗收測試的順序應該是什么？

Question

我正在為使用PHP的項目進行TDD。 到目前為止，我編寫單元測試，使它們失敗，然后編寫最少的代碼來完成測試。 項目完成后，我使用CasperJS編寫驗收測試。

最近，我一直在研究Codeception和Behat以及其他一些測試框架，並且一直在閱讀有關單元測試，集成測試等不同類型的測試。

我無處可找到正確的測試順序。

我想知道的是，當我坐下來設計項目時，我會做：

1. 需求分析
2. 技術棧選擇
3. 枚舉資源/業務實體
4. 然后決定將哪些內容納入模型，將哪些內容保留為服務等。
5. 數據庫設計
6. 填寫必要的型號，控制器，服務清單
7. 在使用phpUnit編寫各個類之前編寫測試
8. API准備就緒后，編寫CasperJS測試以驗證行為。

雖然這並不確切，但可以很好地說明我如何經營商店。 那么，集成測試和行為測試在哪里適合呢？

Answer 1

這確實感覺像是一個基於意見的問題，因此，如果因為這樣而被關閉，請不要感到驚訝。 確實沒有一個完美的答案，決定如何以及何時編寫測試實際上取決於項目和您。

您可以嘗試計算出所有用戶案例和行為，並在第3步之前編寫驗收測試。這可以幫助闡明計划中的暗角。

或者，您可以在啟動功能之前編寫驗收測試。 這可以幫助您了解使用給定功能，其范圍和邊緣情況需要完成的工作。

或者，您可以在項目完成后編寫驗收測試。 這可以用作預期行為的最終檢查清單，然后再交給客戶進行他們想要進行的任何驗收測試。

我敢肯定您的工作流程中還有其他幾點適合編寫驗收測試，但是我發現自己有三點需要編寫驗收測試。 IMO，最佳位置就在開始功能之前。 在這一點上，我有一個用戶故事，我熟悉我已經編寫的代碼，並且對新代碼的預期功能有所了解。

可以組織驗收測試，以與單元測試相同的方式指導編碼，但范圍更廣。 仍然通過“編寫失敗的測試，編寫代碼以通過測試，編寫失敗的測試”進行迭代，但是也有一個更大的循環，由驗收測試驅動。 一旦到達內部循環的某個點，您認為自己將通過合格測試，則通過運行整個套件進行檢查。

您可以通過另一種方式詢問“集成和行為測試適合的位置”，這就是“該測試與我的其余測試和代碼適合的位置”的含義。 這有點少灰色。 單元測試應經常運行。 整個單元測試套件。 經常。 因此，它需要非常快。 您應該能夠知道是否立即破壞了項目內部的某些內容。

那里進行了集成測試，以驗證輸入輸出是否按預期工作。 在您的應用程序之外，您的依賴關系不會改變，而且如果發生改變，您應該意識到這一點很重要。 因此，您的代碼與其代碼之間有明確的界限。 您的單元測試可以帶您直達該界面。 集成測試驗證您編碼的接口確實是他們提供的接口。 您不需要每次小的代碼更改就運行它們。 您確實需要運行它們，但可能僅是每次提交。 他們可能會慢一些。

驗收測試與集成測試類似，只是定義接口，而不是征募外部依賴項來驗證接口是否匹配。 您可以一直運行它們直到發布，但是運行的頻率越高，它們實際提供的價值就越高。

YMMV。