代码遵守单一责任原则和单元测试

我最近一直在阅读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'类正在处理比实际应该承担更多的责任。注入/模拟对象是一种很好的方法，可以测试该方法，而无需实际验证实际通知是否已发送。 –

代码遵守单一责任原则和单元测试

回答

相关问题