單元測試範圍

假設我們有一個遠程服務Alpha，用一個方法GetUser（id，includePurchases）。
該方法具有這樣的規則：

- 如果includePurchases是真的，user.Purchases應該有采購清單。
- 如果沒有，user.Purchases應該是空白的。假設我們有一個網站Beta，帶有一個UserRepository，它有一個方法GetUser（id，includePurchases）。
Beta.UserRepository.GetUser（）在內部調用Alpha.GetUser（）。單元測試範圍

負責Alpha的團隊說Beta應該有一個測試來檢查這個特殊規則。
我不同意，因爲如果你有一個調用服務的單元測試，那是一個集成測試。

他們不希望Beta測試調用Alpha，而是想要一個模擬Alpha.GetUser方法來包含「if（includePurchases）user.Purchases = new List（）」之類的測試。
隨着那個「如果」到位，測試將被寫入斷言user.Purchases是空的或不依賴於includePurchases標誌。

這對你有意義嗎？
他們想要的測試，不應該僅僅是Alpha單元測試的問題嗎？
對我來說，似乎我正在編寫一個測試，檢查有關Alpha工作方式的假設。

來源

2011-06-16 Emanuel

在一個側面說明中，我感覺可能你正在遭受經典組件化開發問題的困擾，它依賴於一個有問題的垃圾組件，並由一個團隊維護，他們拒絕接受他們的完美代碼可能有一個問題。但是，當然你有寫錯誤的問題，因爲QA無法看到Alpha的問題。這是面向組件的軟件開發的典型問題。在建造房屋時，當基礎坍塌時，客戶是否抱怨屋頂工沒有屋頂？ – 2011-06-16 13:12:38

從組件化的角度來看，這聽起來非常正常合法，是的，你是對的，實際上調用Alpha服務的Beta單元測試是集成測試。

請記住，如果您正在爲Beta功能編寫單元測試，那麼您只需對Beta和Beta版本負責。模擬Alpha服務調用是合適的和首選的，因爲您的單元測試應該假設這些外部依賴與廣告完全相同。

通過嘲笑Beta中的功能，您可以保證可重複且一致的單元測試驗證僅ONLY的功能。通過這種方式，如果Beta版流程在環境中失敗，並且您的單元測試通過，那麼Alpha Web服務必須存在問題，然後由其他團隊負責解決並修復此錯誤。

來源

2011-06-16 12:46:55

單元測試範圍

回答

相關問題