更改方法可访问性以对其进行测试答案

【问题标题】：Change method accessibility in order to test it更改方法可访问性以对其进行测试
【发布时间】：2016-02-22 11:36:49
【问题描述】：

我有一个调用一组私有方法的公共方法。

我想用单元测试来测试每个私有方法，因为通过公共方法测试所有东西太复杂了，

我认为仅出于测试目的更改方法可访问性是一种不好的做法。

但我没有看到任何其他方法来测试它（也许是反射，但它很丑）

【问题讨论】：

我真的希望建议的编辑将 pubic method 更改为 public method - 很失望。
stackoverflow.com/questions/34571/…的可能重复
你可以用 groovy 编写你的测试，然后你就可以访问私有方法。 Groovy 还带来了可以轻松创建模拟的优势。
您可以将包本地化，或者质疑是否应该测试私有方法，尝试测试调用这些方法的公共方法。
您的公共方法是您关心的事情。单独测试私有方法并不能保证调用它们的公共方法的任何信息。如果事情“太复杂”而无法通过公共方法进行测试，那么您就该进行重构了。如果您发布一些代码，我们可能会提供更多帮助。

标签： java unit-testing testing tdd

【解决方案1】：

私有方法应该只作为重构公共方法的结果而存在，该公共方法是您使用 TDD 开发的。

如果您创建一个具有公共方法的类并计划向其添加私有方法，那么您的架构将会失败。

我知道这很苛刻，但您要求的是非常非常糟糕的软件设计。

我建议你买鲍勃叔叔的书《干净的代码》

http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

这基本上为您提供了一个很好的基础，可以让您在未来成为一名开发人员时做好准备并为您省去很多烦恼。

【讨论】：

【解决方案2】：

IMO 对这个问题只有一个正确答案；如果这个类太复杂，就意味着它做的太多并且有太多的责任。您需要将这些职责提取到可以单独测试的其他类中。

所以你的问题的答案是NO！

您所拥有的是代码气味。你看到了问题的症状，但你没有治愈它。您需要做的是使用重构技术，例如 extract class 或 extract subclass。尝试看看您是否可以将其中一个私有方法（或其中的一部分）提取到自身的类中。然后您可以将单元测试添加到该新类。分而治之，直到您控制代码。

【讨论】：

【解决方案3】：

如前所述，您可以将可见性从私有更改为包，然后确保单元测试在同一个包中（通常情况下应该如此）。

考虑到（现在）私有函数的接口足够稳定，并且您还进行了一些集成测试（即检查公共方法在正确的方法）。

不过，您可能还需要考虑其他一些选项：

如果私有函数是接口稳定但足够复杂的，您可以考虑为它们创建单独的类 - 其中一些可能会受益于被拆分为几个较小的函数本身。
如果通过公共接口测试私有函数不方便（可能是因为需要复杂的设置），有时可以通过使用简化设置并允许不同测试共享通用设置代码的辅助函数来解决此问题.

【讨论】：

【解决方案4】：

你是对的，改变方法的可见性只是为了让你能够测试它们是一件坏事。以下是您的选择：

通过现有的公共方法对其进行测试。您确实不应该测试方法，而是测试行为，这通常需要多种方法。因此，不要再考虑测试该方法，而是要找出未测试的行为。如果你的类设计得很好，它应该很容易测试。

将方法移到新类中。从设计角度来看，这可能是解决您的问题的最佳方法。如果您的代码非常复杂以至于您无法访问该私有方法中的所有路径，那么它的一部分可能应该存在于它们自己的类中。在该类中，它们至少具有包范围并且可以轻松测试。再说一遍：你仍然应该测试行为而不是方法。

使用反射。您可以使用反射访问私有字段和方法。虽然这在技术上是可行的，但它只是将更多的遗留代码添加到现有的遗留代码中以隐藏遗留代码。在一般情况下，这是一件相当愚蠢的事情。这也有例外。例如，由于某种原因，您甚至不允许对生产源代码进行最小的更改。如果你真的需要这个，谷歌它。

只需更改可见性是的，这是不好的做法。但有时替代方案是：在没有测试的情况下进行大的更改，或者根本不测试。所以有时可以硬着头皮改变能见度。尤其是当它是编写一些测试然后在其自己的类中提取行为的第一步时。

【讨论】：