用途：生成可直接用于生产的 Apex 测试类，并通过规范化的测试-修复循环配合覆盖率分析进行验证。
核心原则：每个测试方法只验证一个场景，正例、反例与批量测试分开，不把相近但不同的输入（如 null 与空）合并；使用 251+ 记录跨过 200 条触发器批次边界（Batch Apex 例外：测试上下文只执行一次 execute()，需令 batchSize >= 记录数）；测试数据隔离，@TestSetup 必须委托给 TestDataFactory 创建记录，不内联构建列表、不依赖组织数据或硬编码 ID；使用精确期望值与失败消息，仅用 Assert 类（Assert.areEqual/isTrue/fail），不用 System.assert 旧方法；用 HttpCalloutMock、Test.setFixedSearchResults、DML mock 隔离外部边界；覆盖负向路径；用 Test.startTest()/Test.stopTest() 重置限制并同步执行异步。
工作流：先收集上下文（被测类、现有测试与工厂、范围、覆盖率阈值、组织别名），再生成测试类，必须同时产出 {ClassName}Test.cls 与 {ClassName}Test.cls-meta.xml（默认 apiVersion 66.0），缺失时创建 TestDataFactory.cls 及其 meta。使用 Given/When/Then 结构，命名如 should[ExpectedResult]_When[Scenario]。运行示例：sf apex run test --class-names MyServiceTest --result-format human --code-coverage --target-org <alias>。随后分析失败方法与未覆盖行，进入最多 3 次迭代的修复循环，仍失败则停止并暴露根因。覆盖率：部署最低 75%，建议 90%+，关键路径 100%。组件场景涵盖 Trigger、Service、Controller、Batch、Queueable、Callout、Selector、Scheduled、Platform Event。反模式包括循环内 SOQL/DML、魔法数字、超大测试类（>500 行）、过长方法（>30 行）、泛化异常捕获。限制：资料未提供价格、平台范围或实际效果数据。