通过使用私有方法合理地减少了循环复杂性？

Question

使用私有方法通过将一些决策点重构为单独的方法来减少CC会降低实际方法的CC并简化读取，但不会减少在测试中获得完整分支覆盖的工作量。

这是否合理？你有什么实地经验？

Answer 1

有时，使应用程序代码不那么复杂和可读性会导致测试代码变得更复杂，可读性也更低。但是，这不是不进行重构的原因。生产代码的可读性比您的测试更重要。

如果你为减少CC和提高可读性而使一些方法变得私有，你可以使用像Mockito这样的框架来自己测试私有方法。

Answer 2

根据我的经验，这是一种非常常见的情况 - 使您的生产代码做正确的事情使得测试更加困难其他示例包括隐藏接口背后的实现细节，永远不会将ORM实体传递给外部调用者，从而实现某些功能仅通过Web服务调用提供...并且通常在生产中具有您期望的API会经常限制测试。

是的，在经过大量重构后，您的覆盖范围很难恢复。有时，如果没有正确测试那么难以测试的功能，这会导致整体进度发生逆转。所以我普遍同意Fortega，除了最后一句。不要让你的测试腐烂。当你最不想要的时候，他们会回来。

Answer 3

我真的不明白你的问题。显然，将大型方法中的逻辑和决策点重构为私有方法将减少大型方法的圈复杂度。这是提取方法的一点 - 它使大方法更简单，更容易理解和改变。

这不是作弊，它只是简单地使程序的结构。

  

但不会减少努力   在测试中获得完整的分支覆盖。

对我来说，这似乎是不合理的。为什么要将私有方法分解出来使覆盖测试更容易？我从未见过有人声称这一点。你可能误解了什么吗？

Answer 4

如果您仍然感兴趣，那么我在Cyclomatic Complexity

上写下了这篇文章

使用不同的方法切割代码不会降低复杂性，但只会帮助本地更好地组织。减少CC的唯一真正方法是重构！

如果只提取方法，则需要相同数量的测试。看看你的数据结构可能是他们没有帮助你吗？如果它有感觉，请考虑切入几个班级。

Answer 5

你不应该重构你的代码，因为人们认为提高度量标准的数量对你的代码有好处。而不是去寻找数字和花哨的报告（我不幸地看到了这一点），你应该首先了解指标及其使用的原因。

Cyclomatic Complexity是一个简单的数学度量，它只说明如果所有分支都被导航，您的代码可以执行多少条不同的路径。所以，是的，高Cyclomatic Complexity确实表明您的测试可能变得更加复杂。但有时用高CC和大量测试编写代码根本就没有简单的方法。您只需要知道何时这是一种公平的做法以及何时您的设计出现问题。在旁注中，通过将代码分割为方法来减少CC并不会简化测试任务，因为必须以任一方式覆盖代码。这只是看起来“更漂亮”的数字。

请考虑以下事项：您的任务是设计对按键做出反应的代码，并根据按下的键执行某些任务。该设备仅具有固定数量的按钮，这意味着软件首先需要详尽无遗，无需扩展（采用该命令模式）。

您可以编写一个简单的switch语句，该语句易于阅读，每按一个按钮触发一个方法。这将是快速有效地解决此任务的好方法。但获得关键压力的方法的CC将是可怕的。你应该拆分代码吗？为什么？我的意思是它是可读的，完美地服务于它的目的，无论你做什么，你的测试仍然需要考虑每个按钮按下。因此，除了减少重数之外，重构没有任何好处。

我的建议是学习Cyclomatic Complexity何时是一个有意义的指标，什么时候不是。另外，从他的blog post尝试一下Micheal的一些重构建议。它有一些可靠的建议。