我有一个调用私有方法组的公共方法。
我想用单元测试测试每个私有方法，因为通过公共方法测试所有内容太复杂了，
认为仅出于测试目的更改方法可访问性将是一种不好的做法。
但我看不到任何其他方法来测试它（也许是反射，但它很丑陋）
私有方法应该只作为重构公共方法的结果而存在，这是您使用TDD开发的。
如果使用公共方法创建一个类并计划向其添加私有方法，则体系结构将失败。
我知道这很苛刻，但你所要求的是非常非常糟糕的软件设计。
我建议你买鲍勃叔叔的书《清洁代码》
http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
这基本上为你打下了良好的基础，让你在未来作为开发人员时避免了很多悲伤。
这个问题只有一个正确答案;如果类太复杂，则意味着它做得太多，责任太多。您需要将这些职责提取到可以单独测试的其他类中。
所以你的问题的答案是否定的！
你拥有的是代码气味。你看到了问题的症状，但你没有治愈它。您需要做的是使用重构技术，如提取类或提取子类。尝试查看是否可以将这些私有方法之一（或其部分）提取到自身的类中。然后，可以将单元测试添加到该新类。分而治之，直到你控制了代码。
如前所述，您可以将可见性从私有更改为包，然后确保单元测试位于同一包中（无论如何通常都应该如此）。
对于您的测试问题，这可能是一个可接受的解决方案，因为（现在）私有函数的接口足够稳定，并且您还进行了一些集成测试（即，检查公共方法是否以正确的方式调用私有方法）。
但是，您可能需要考虑其他一些选项：
- 如果私有函数是接口稳定的，但足够复杂，则可以考虑为它们创建单独的类 - 其中一些函数本身可能会从拆分为几个较小的函数中受益。
- 如果通过公共接口测试私有函数不方便（可能是因为需要复杂的设置），有时可以通过使用帮助程序函数来解决这个问题，这些函数简化了设置并允许不同的测试共享通用设置代码。
你是对的，改变方法的可见性以便能够测试它们是一件坏事。以下是您拥有的选项：
通过现有的公共方法对其进行测试。你真的不应该测试方法，而应该测试行为，这通常需要多个方法。因此，不要再考虑测试该方法，而是要找出未测试的行为。如果你的类设计得很好，它应该很容易测试。
将该方法移动到新类中。从设计的角度来看，这可能是解决问题的最佳解决方案。如果您的代码非常复杂，以至于无法访问该私有方法中的所有路径，则其中的某些部分可能应该位于自己的类中。在该类中，它们至少具有包范围，并且可以轻松测试。再次：您仍然应该测试行为而不是方法。
使用反射。您可以使用反射访问私有字段和方法。虽然这是技术上可行的，但它只是向现有的遗留代码添加更多的遗留代码，以隐藏遗留代码。在一般情况下，这是一件相当愚蠢的事情。这也有例外。例如，由于某种原因，您甚至不允许对生产源代码进行最小的更改。如果你真的需要这个，谷歌一下。
只需更改可见性 是的，这是不好的做法。但有时替代方案是：在没有测试的情况下进行重大更改或根本不测试它。所以有时候咬紧牙关改变能见度是可以的。特别是当它是编写一些测试然后在自己的类中提取行为的第一步时。