如何对内部调用了已测internal/private/helper方法的公共服务方法做单元测试

首先直接回答你的核心问题：private方法无法直接mock，internal方法可以通过配置实现mock，更建议优先用架构调整的方式降低测试成本，具体操作如下：

非公开方法的mock实现方式 #

• private方法：受C#语法限制，所有主流mock库（Moq、NSubstitute、FakeItEasy等）都不支持直接mock非虚的私有方法。如果一定要绕开执行，只能用反射的方式替换方法指针，实现成本极高，且会让测试代码和内部实现强绑定，后续只要内部方法改个名或者改个参数，测试代码全崩，完全不推荐这么做。
• internal方法：只需要两步就可以实现常规mock：
  1. 在服务项目的AssemblyInfo.cs文件中添加配置，把内部成员对测试项目可见：[assembly: InternalsVisibleTo("你的测试项目程序集名称")]，如果项目用了强签名，需要额外把测试项目的公钥也加进去。
  2. 把需要mock的internal方法标记为virtual，之后就可以和mock接口方法一样，自定义它的入参匹配规则和返回值，不需要执行实际逻辑。

更推荐的落地实践 #

单元测试本质是测公开接口的行为正确性，不是测内部实现细节。你已经完成了所有非公开方法的单元测试，测公共方法时完全不需要重复验证这些方法的内部逻辑。

• 优先把复用度高的helper逻辑抽成独立的服务，定义对应的接口注入到当前服务中。测试公共方法的时候直接mock这个helper服务的接口即可，这是最符合.NET依赖注入规范的方案，后续维护成本最低。
• 如果不想拆分现有服务结构，公共方法的单元测试只需要覆盖它独有的逻辑分支：比如入参校验、多个内部方法调用的编排逻辑、内部方法返回值的聚合处理逻辑即可，所有已经被内部方法覆盖的边界case完全不需要重复测试。

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