如何为依赖私有方法的两个公共方法编写单元测试？

首先明确核心原则：无需直接测试私有方法，私有方法是公共方法的实现细节，测试公共方法的整体行为，自然就覆盖了私有方法的执行逻辑——这完全符合“无需测试私有方法”的最佳实践，不用纠结单独去覆盖私有方法。

下面分两种情况讲具体的测试方案：

1. 测试otherPublicMethod #

这个方法是独立的公共方法，参数是ComplexObject，测试时完全不用关心这个对象的来源：

• 手动构造各种场景的ComplexObject实例（比如正常数据、边界值、异常数据）
• 把这些实例传入otherPublicMethod，验证返回结果是否符合预期
• 重点覆盖这个方法的业务逻辑分支，确保它能正确处理所有输入情况

2. 测试MyPublicMethod #

这个方法依赖私有方法生成ComplexObject，再调用otherPublicMethod，有两种可行的测试思路：

思路一：端到端测试公共方法的整体行为 #

这是最直接的方案，不需要改动现有代码：

• 给MyPublicMethod传入不同的Data输入（对应不同业务场景）
• 根据Data的特征，推导MyPrivateMethod应该生成的ComplexObject（这一步是对私有方法逻辑的业务理解，不是硬编码实现细节）
• 结合otherPublicMethod的已知行为，计算MyPublicMethod的预期最终结果，然后验证实际输出是否匹配
• 这种方式下的“硬编码预期值”是合理的，因为你是基于业务规则推导的结果，不是绑定私有方法的实现细节

思路二：重构隔离依赖（可选，针对复杂场景） #

如果MyPrivateMethod逻辑极复杂、或者依赖外部资源（比如数据库、API），导致测试MyPublicMethod时难以构造输入，可以考虑重构：

• 把MyPrivateMethod的逻辑提取到一个独立的类（比如ComplexObjectGenerator），并定义公共接口
• 让原类依赖这个接口，在MyPublicMethod中通过接口调用生成ComplexObject
• 测试MyPublicMethod时，用Mock工具模拟这个接口，返回预设的ComplexObject，这样就能隔离私有方法的逻辑，专注测试MyPublicMethod调用otherPublicMethod及后续的逻辑
• 这个方案的核心是把实现细节转为可注入的依赖，既保持了原类的封装性，又方便测试，同时也让代码更易维护

关于测试覆盖率的补充 #

提升覆盖率的正确方式是覆盖公共方法的所有业务场景，而不是强行测试私有方法。如果发现私有方法的某些分支没有被公共方法的测试覆盖，说明要么这些分支是冗余代码，要么是公共方法的测试场景不全——这时候应该补充公共方法的测试用例，而不是去单独测试私有方法。

内容的提问来源于stack exchange，提问作者Blerdegerb