具有高凝聚力但相当复杂的逻辑的测试课程

Question

例如，我有一个采用原始数据，分析数据并返回报告数字的类。让我们把它SomeReportDataProvider

class SomeReportDataProvider 
{ 
    public function report(array $data) 
    { 
     $data = $this->prepare($data); 

     $report = []; 
     foreach ($data as $item) { 
      if ($row->somefield == 'somevalue') { 
       $report = $this->doThis($report, $row); 
      } else { 
       $report = $this->doThat($report, $row); 
      } 
     } 

     // ... do something else 

     $report = $this->postProcess($report); 

     return $report; 
    } 

    protected function doThis($item) 
    { 
     // ... do some math, probably call some other methods 
    } 

    protected function doThat($item) 
    { 
     // ... do other math 
    } 

    // ... and so on 
} 

所以该类确实只有一件事，一步一步的一些报告的原始数据的等待处理。这不是很大，最有可能的方法有5-10行。它的所有方法都是紧密相关的，并且有一个目的，所以我认为它具有很高的凝聚力。但是什么是测试班级的最佳方式？

如果我尝试的心态“测试行为，不执行”办法吧，我应该测试仅是单一的公共方法。这种方法的优点在于，即使未触及测试，也可以很容易地重构类，并且我确信它仍然具有完全相同的行为。但是通过单一方法覆盖所有情况也可能非常困难，可能的代码路径太多。

我可以让大部分（可能全部）的方法public和隔离测试他们，但后来我打破阶级和算法的封装和测试它的实现细节。任何重构都将变得更加困难和不必要的行为变化。

作为最后一种选择，我可以将它分成小类，最有可能有1或2种方法。但是将高度凝聚力的课堂分成更小，紧密耦合的课程，是否真的是一个好主意，这些课程做的非常具体，并且不会在其他地方重复使用？而且重构仍然会更困难。对于其他开发人员来说，可能很难快速了解它的工作原理。

Answer 1

我总是试图去为分手了班尽可能，就像你在你的最后一个选项说，因为在我的经验，这是简化测试的最好方式，这本身就是一个非常有效的理由...
另外，我不同意你的看法 - 我觉得这个方法可以更容易地在未来的重构，并更容易理解，而不是一个大的类都在一起......

你的代码来看，我可以看到一堆单独的“角色”：ReporterInterface,Reporter,ReportDataPreparator,ThisDoer,ThatDoer,ReportPostProcessor（显然你可以找到更好的名字:)

你可能想要重用他们中的一些在未来，但即使不是这样，所有这些都是非常具体的报告，你可以把它们放在一个单独的命名空间和文件夹（如“报告模块” ）。
该报告模块都有一个独特的API，这是你的ReporterInterface，和系统的所有其他部分只需要关心这个接口，不论是记者是否使用私有方法，其他类，或者在后台一个完整的系统 - 他们只需要调用$reporter->report($data) ...

因此，从系统的其余部分的角度来看，没有什么变化，您的报告服务仍然都在一起，和你的单元测试是多更容易编写和维护...