Salesforce Org测试实践：是否每个APEX类都需对应单独的测试类？

将组织内80%的APEX测试代码都归到同一个测试类的设计，确实不是最优方案，在实际开发迭代中会带来诸多明显问题：

• 维护难度陡增：单测试类代码量过大时，不管是排查测试失败用例，还是修改对应业务逻辑的测试规则，都需要在动辄数千行的文件里逐行检索，开发效率会受到极大影响
• 测试执行耗时变长：Salesforce平台的测试调度逻辑对单个超大测试类的优化支持很差，无法将类内部的测试方法拆分到不同节点并行执行，全量测试的运行时长会被大幅拉长，直接影响CI/CD流水线的效率
• 代码冲突概率极高：多个开发者同时迭代不同业务模块的测试用例时，几乎必然会在同一个测试类文件上产生代码冲突，额外增加大量代码合并的工作量
• 不符合平台最佳实践：Salesforce官方明确推荐测试类和业务类一一对应，例如业务类为AccountService.cls时，对应的测试类应命名为AccountServiceTest.cls，方便快速关联业务代码和对应的测试覆盖逻辑
• 覆盖率统计不直观：无法按业务模块拆分查看测试覆盖率，也很难快速定位某一模块的测试覆盖缺口。

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