如何在C#中Mock NuGet包中的复杂类？以Impinj OctaneSdk为例

• 增量式适配器模式
  不要试图一次性为SDK所有类实现接口，而是只针对当前测试场景需要的功能做适配。比如先给阅读器的核心行为（连接、断开、触发标签事件）定义极简接口，再写一个包装类适配SDK的具体实现；对于Tag这类数据类，同样只包装业务代码用到的属性。这种方式只处理测试相关的部分，避免无意义的大量重复工作，同时隔离SDK的具体实现与业务逻辑。

• 手动实现测试替身
  放弃依赖Moq等动态Mock工具，自己编写极简的测试替身类。比如写一个FakeReader类，内部维护连接状态，提供手动触发标签事件的方法，传递自定义的FakeTag对象。这类替身不需要复刻SDK的所有功能，只需要模拟测试场景（比如网络断开、重连成功、标签读取）需要的行为，完全可控且实现成本低。

• 逐步落地依赖反转原则
  重构业务代码，让核心逻辑依赖你自己定义的抽象（接口/抽象类），而非SDK的具体类。从需要测试的模块（比如重连逻辑）开始，先把这部分代码依赖的SDK类替换为抽象接口，再分别实现真实SDK的适配类和测试用的替身类。这种方式不仅解决测试问题，还能提升代码的可维护性，后续更换SDK或扩展功能时更灵活。

• 挖掘SDK自带的测试支持
  检查SDK是否提供官方模拟器、调试模式或测试工具。有些硬件SDK会自带模拟设备，能模拟网络故障、标签读取等场景，直接用这些工具可以避免Mock的麻烦。如果没有官方工具，也可以查看SDK是否允许替换底层通信组件（比如自定义网络客户端），通过模拟通信异常来测试重连逻辑。

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