测试具有高内聚力但逻辑相当复杂的类
例如，我有一个类，它获取原始数据，对其进行分析，然后为报告返回数字。让我们称它为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
}所以这个类实际上只做了一件事，一步一步地处理一些报告的原始数据。它不是很大，最有可能是4-6个方法，5-10行。它的所有方法都是紧密相关的，并且只有一个目的，所以我想说它有很高的内聚力。但是测试这个类的最佳方法是什么呢？
如果我试图以“测试行为，而不是实现”的心态来处理它，我应该只测试它的单个公共方法。这种方法的优点是，它很容易在以后重构类，甚至不需要接触测试，我可以肯定它仍然表现出完全相同的行为。但是也很难通过单一的方法覆盖所有的情况，太多可能的代码路径。
我可以让大多数(可能是所有)方法公开并单独测试它们，但是这样我就打破了类和算法的封装，并测试了它的实现细节。任何重构都会变得更加困难，而且更有可能出现不必要的行为变化。
作为最后一种选择，我可以把它分成几个小类，很可能只有一两个方法。但是，将高度内聚的类分解成更小的、紧密耦合的类，这些类做非常具体的事情，并且不会在其他地方重用，这真的是一个好主意吗？此外，重构仍然会更加困难。对于其他开发人员来说，可能更难快速了解它的工作原理。
回答 1
Stack Overflow用户
发布于 2017-10-13 18:18:24
我总是尝试尽可能多地划分类，就像你在上一个选项中所说的那样，因为根据我的经验，这是简化测试的最好方法，这本身就是一个非常有效的原因……
此外，我不同意你的观点--我认为这种方法使未来的重构更容易，也更容易理解，而不是把所有东西都放在一起的大类……
查看您的代码，我可以看到一堆独立的“角色”：ReporterInterface、Reporter、ReportDataPreparator、ThisDoer、ThatDoer、ReportPostProcessor (显然您可以找到更好的名称:)
您可能希望在将来重用其中的一些，但即使情况并非如此，并且它们都非常特定于报表，您也可以将它们放在单独的名称空间和文件夹中(就像“报表模块”一样)。
这个报告模块有一个独特的接口，那就是你的ReporterInterface，你的系统的其余部分只需要关心这个接口，不管报告器是使用私有方法，其他类，还是整个系统在后台-他们只需要调用$reporter->report($data)...
因此，从系统其余部分的角度来看，没有任何变化，您的报告服务仍然在一起，并且您的单元测试更易于编写和维护…
https://stackoverflow.com/questions/46727269
复制相似问题
腾讯云开发者
