测试中能否复用生产代码？三种实现方案优劣及选型咨询

选型核心考量点 #

方案1（测试侧独立实现转换逻辑）的额外注意事项 #

• 仅适合转换逻辑长期稳定、变更频率极低的场景。如果后续业务迭代需要修改字段映射规则，你需要同时修改生产和测试两套逻辑，一旦漏改要么测试漏报问题，要么出现大量误报，维护成本会随逻辑复杂度上升指数级增长。
• 你需要保证测试侧的转换逻辑是100%符合业务预期的「真值标准」，如果测试逻辑本身就写错了，反而会把正确的生产代码判定为异常，排查成本极高。
• 对于字段数量多、转换规则复杂的场景，两套逻辑的对齐本身就是额外工作量，你需要额外投入成本验证测试侧逻辑的正确性。

方案2（抽公共工具类复用）的适用场景&优势 #

• 更适合转换逻辑会随业务迭代频繁调整的场景，一套逻辑修改一次即可，不会出现生产和测试逻辑不同步的问题。
• 你担心的「生产逻辑有bug测不出来」的问题可以换方式规避：不需要用转换后的结果做全量校验，只需要针对核心字段做独立校验即可，比如直接从DB查询结果里取report_id、status_id等关键字段，和转换后的Report对象字段做比对，不需要完全重写全套转换逻辑。
• 抽公共类本身也是对遗留代码的小范围重构，不会影响原有生产逻辑的稳定性，还能提升代码可维护性。

方案3（改生产方法访问权限）的折中选项 #

• 如果不想动生产代码结构，又不想重复写逻辑，这是成本最低的方案，只需要把private改成包级私有（默认访问权限），测试类和生产类放在同一个包路径下即可，不需要对外暴露方法，也不会引入额外的维护成本。
• 这种方案不会影响生产代码的安全性，因为包级私有仅对同包下的类可见，对外仍然是隐藏的，符合封装原则。
• 同样可以搭配「核心字段独立校验」的逻辑，既复用了生产转换代码，又能验证转换结果的正确性，不会出现生产有bug测不出来的问题。

集成测试场景的特殊建议 #

因为你用的是真实DB做集成测试，本质上要验证的是两个点：1. SQL查询能返回预期的原始数据 2. 转换逻辑能把原始数据转换成符合预期的Report对象。你可以把两个验证点拆开：

• 先单独验证SQL查询返回的原始字段值符合预期，直接和DB里的预置测试数据比对
• 再验证转换逻辑的正确性，这一步如果用方案2或者3，就不需要重复写转换逻辑，只需要比对转换后的对象和预期值即可，完全可以覆盖生产逻辑的bug。

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