代碼遵守單一責任原則和單元測試

我最近一直在閱讀Single Responsibility Principle概念，理論上我很同意它。我很難說明哪些代碼可以被嚴格分類爲違反該原則。我想實施這個原則，以便推動測試驅動開發。代碼遵守單一責任原則和單元測試

例如下面的代碼

採取：

public void MarkAsSuccessful(PaymentMethodSpecific paymentMethod, bool requiresManualIntervention) 
    { 
      this.Paid = true; 
      this.PaidOn = CS.General_v3.Util.Date.Now; 
      this.PaidByPaymentMethod = paymentMethod; 
      this.RequiresManualIntervention = requiresManualIntervention; 

      this.Update(); 

     this.CreateAndSendNotificationRegardingImmediatePayment(); 

     this.SendPaymentSuccessfulEmails(); 

    }

這被放置在稱爲PaymentRequest類，它基本上是處理在電子商務應用有關付款邏輯的類。上述方法將請求標記爲「成功」。這必須標記已付費欄目以及其他信息，併發送通知表示已成功，併發送電子郵件。

例如，當涉及到單元測試時 - 單元測試這種方法非常困難，因爲我無法知道通知是實際創建和發送的，還有付款電子郵件已發送。想知道在SRP概念上有多少經驗豐富的人會接近這樣一個例子。

來源

2012-08-23 Karl Cassar

這裏您可能會遇到更深層次的問題。你明白爲什麼名爲'CreateAndSend ...'的方法會違反SRP嗎？ –

@AustinSalonen我明白你的意思了，我不同意：如果他總是創建**和**發送通知會怎麼樣？如果該方法只是調用其他兩種方法，那就沒有問題。 SRP一個非常常見的錯誤是試圖在100％的時間內應用它。 –

我的猜測是你有一個PaymentProcessor類合併/嵌入在PaymentRequest類。

PaymentProcessor基本上是PaymentRequest經過的有限狀態機。

在構建此PaymentProcessor時，您將注入可處理「即時付款通知」和一般電子郵件的對象。通過這種方式，您可以通過注入模擬對象來測試所有獨立狀態和處理器狀態，這些模擬對象聲明發生了預期條件。

單一職責本身就是一個很好的概念，但是當你開始投資整體SOLID時，權力才真正來到。

來源

2012-08-23 16:42:16

+1對於有限狀態機部分 – ewernli

@AustinSalonen是的，我同意這個'PaymentRequest'類正在處理比實際應該承擔更多的責任。注入/模擬對象是一種很好的方法，可以測試該方法，而無需實際驗證實際通知是否已發送。 –

代碼遵守單一責任原則和單元測試

回答

相關問題