为提升可测试性修改类接口是否合理？接口设计与可测试性如何权衡

为了可测试性修改类接口是否可行？ #

完全可行，但需要把握改动的边界。
依赖注入、面向接口编程本身就是面向对象设计的通用最佳实践，并非仅服务于测试的特殊改动。如果你觉得这类调整会对接口设计造成负面影响，多数情况是当前类本身就存在依赖耦合过深、职责边界模糊的问题，拆分抽象的过程刚好暴露了原有设计的缺陷。
当然也存在过度调整的情况：如果为了测试一个仅在类内部生效、无关核心业务逻辑的极小工具组件，强行将其提升为对外公开的构造参数，导致类的对外接口暴露了不必要的实现细节，这种为了测试无底线改动接口的行为是不可取的。

接口设计和可测试性的优先级如何判断？ #

二者本质上并非对立关系，不需要非此即彼地排优先级。
可测试性本身就是评价接口设计质量的核心指标之一：一个难以编写单元测试的类，几乎必然存在依赖耦合过死、职责不单一的设计问题。你感受到的冲突，大多是两种情况导致的：

• 你对"合理接口设计"的判断存在偏差，把"原有写法"误当成了"最优设计"，把优化依赖结构的正常调整当成了对接口的破坏
• 为了测试做了不必要的过度设计，比如为了方便mock把本应封装的内部方法改为public，破坏了接口的封装性
  如果确实出现不可调和的冲突，优先保证核心接口的封装性和易用性，不要为了测试牺牲接口的核心设计目标，这种情况可以考虑换用集成测试等其他测试方案覆盖逻辑。

提问需要通用形式还是附上具体示例？ #

建议附上具体代码示例。
通用讨论只能输出原则性的判断标准，没有办法适配你的具体场景：你要拆分的组件是核心业务依赖还是内部工具类？调整后构造参数的数量、调用方的兼容成本有多大？这些信息都会直接影响方案的合理性判断，只有结合具体代码片段，才能得到更准确、可落地的建议。

内容的提问来源于stack exchange，提问作者Christian H.