辅助类与外观类的注入及测试断言方案选型咨询

你的思路完全正确，优先选择**不注入FooItem、测试断言Foo**的方案更合理，下面针对两个核心议题拆解说明：

一、实例化Bar时是否需要注入FooItem？ #

• 核心原则：如果FooItem是纯粹的内部外观/辅助工具类（仅封装Foo的操作逻辑，自身已完成测试），不需要注入。
  • 注入的本质是解耦核心协作依赖，但FooItem属于Bar实现细节的一部分，而非Bar的业务协作对象。硬注入会增加不必要的代码复杂度，反而让Bar耦合到实现工具，而非它真正要完成的目标（和Foo交互）。
  • 例外场景：如果未来明确需要替换FooItem的实现（比如不同环境下适配不同的Foo交互方式），可以先定义一个FooOperator接口，让FooItem实现该接口，再将接口注入Bar——但这是针对明确的扩展性需求，而非为了测试而过度设计。

二、Bar的测试该断言Foo还是FooItem？ #

• 结论：必须断言Foo的状态或行为，而非FooItem。结合你的思考展开：
  • 避免测试牵连：FooItem已有独立测试，它的bug不该导致Bar的测试失败。Bar的测试只需要验证自身逻辑是否正确触发了预期的Foo操作，中间工具的问题应该由工具自身的测试覆盖。
  • 聚焦业务职责：Bar的核心价值是完成和Foo的交互，FooItem只是实现这个目标的手段。断言FooItem相当于测试“Bar是否会用某个工具”，而非“Bar是否完成了它该做的事”，完全偏离了测试的核心目的。
  • 保持测试稳定性：如果未来替换FooItem（比如改成直接调用Foo的方法，或者换一个新的外观类），只要最终对Foo的操作逻辑不变，Bar的测试就能直接通过，不需要修改测试代码——这才是测试应该具备的“抗变更”特性。

补充：如果Foo是外部依赖（比如数据库、第三方服务），测试时可以用模拟对象（Mock）替代真实的Foo，断言模拟对象的方法调用即可，核心依然是围绕Foo，而非FooItem。

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