在@Configuration中为测试创建相同Bean是否违反DRY原则？

首先给出明确结论：这种直接复制业务代码中Bean定义到测试配置的操作，确实违反DRY原则。

DRY原则的核心是同一份逻辑/配置仅在一处做唯一维护，复制代码的行为会带来两个明显问题：

• 后续业务代码中B、C Bean的逻辑迭代时，你需要手动同步修改测试配置中的副本，一旦漏改就会出现测试运行上下文和线上真实运行上下文不一致的问题，最终导致测试结果完全失去参考价值
• 冗余代码会提升整体维护成本，你需要同时维护两份逻辑完全一致的Bean代码，没有任何收益

针对你的测试场景，你可以根据测试类型选择更合理的方案，完全不需要复制代码：

• 如果你做的是类A的单元测试：不需要引入真实的B、C Bean实现，直接用对应技术栈的Mock工具（比如Java栈的Mockito、Python栈的unittest.mock）模拟B、C的预期返回行为即可，仅验证类A的内部逻辑正确性
• 如果你做的是集成测试，必须依赖真实的B、C Bean运行：直接在测试的上下文配置中引入业务代码的Bean扫描路径，或者显式引用业务侧定义的B、C Bean即可，测试代码可以合法依赖业务侧的公共实现，这是符合项目规范的常规操作

作为测试新手不需要有顾虑，这个问题是刚接触依赖注入体系测试的开发者非常容易碰到的常见疑问，完全不存在过于基础的问题。

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