单元测试私有方法似乎使整个解决方案更容易

Question

让我们假设有一个实用程序类（无数据）与一个复杂（如在，难以测试）公共方法。它使用随机数生成，返回大量数据和有趣的东西。但是，如果您使用小型私有方法实现它，则每个私有方法都将很容易测试，因此整个事情将更容易测试。从应用的角度来看，只有大的方法需要公开，而另一个应该是私人的。然而，测试私有方法会使测试更容易。我应该如何处理这个问题？

Answer 1

无论你是否应该将你的方法作为一个单独的黑箱算法，其子部分不可测试，或试图将尽可能多的责任尽可能地分离出来，都是非常具有情境性的。

您可能有可能会被重复使用的子部分，在这种情况下，最好将它们排除。您可能有与其他层或硬件交谈的子部分 - 同样的事情。

这一切都取决于这些小的子方法做什么，很难说没有上下文。

Answer 2

有时产生随机数字，返回大数组和其他有趣的东西意味着单个工具类负责多个事物，这意味着应该有更多的类来代替。单一课程中的高复杂性（单一方法！）有时是不良设计的标志。但是，从来没有一条金科玉律可以遵循。

Answer 3

只有测试一个类的公共API有一个非常强烈的论据。它使重构代码变得容易得多，因为除非您更改方法签名，否则单元测试不需要更改，他们将验证您的更改没有破坏任何内容。

有人说有时候测试私有方法是有意义的（尽管这可能是例外 - 而不是规则）。有些测试框架（例如MSTest）允许您为此目的访问私有成员，而另一些（例如nUnit）则不会因为他们认为您不应该这样做（在.Net的情况下，它并不需要太多尽管写你自己的反射类/方法给你访问）。

如果您决定测试您的私有方法，请确保您也测试完整的公共方法，因为您需要公开测试来验证您以后的重构，如上所述。

Answer 4

需要测试私有方法应该是一个警告标志。这不是解决您的大而复杂的方法。将功能提取到更小的类中是解决方案，简化单个Responsibility Principle（SRP）。 SRP指出，一个班级应该只做一件事。

随机数字生成，数组处理和有趣的东西至少是三个独立的东西，应该分开完成。

Answer 5

测试私人会员将总是让你的测试变得脆弱。当你测试私有方法时，你的测试依赖于可以并且经常改变的实现细节。您之所以提供私密性是因为您希望能够在不影响其他软件的情况下对其进行更改。猜猜看：如果你暴露了你的私人物品，即使它只使用反射“黑魔法”，你也会公开它们，因为你的测试也是你的软件的一部分。

如果你觉得你必须测试的实施细则，是否因为你的公共API确实太多，还是因为私有方法是如此的重要，你应该重构你的代码和你的私有成员提取物作为公开课和测试那些。记住，因为你的测试也是软件的一部分，所以他们应该对他们使用的代码有“正常”的访问权限。

如果你坚持认为这些（不是）私有方法不能公开，也许是因为害怕允许外部用户/代码访问它们，你可以通过让它们访问这些类来限制这些类的内部（在C＃）或程序包专用（使用Java），并让代码的内部对您的测试可见。

无论哪种方式，这听起来你的代码应该不被测试或应该公开（更多）。