前端单元测试覆盖范围：Angular模板与组件类测试选择

结论先行：类方法和模板都需要测试，但二者测试定位完全不同，不要做重复的无效测试。

组件类方法：做纯逻辑的全覆盖测试 #

你写的amICo3pmCompany、noActiveAgreement属于承载核心业务规则的纯逻辑方法，这部分是单元测试的第一层防线，必须单独覆盖所有边界分支：

• 测试amICo3pmCompany时，不需要渲染模板，直接实例化组件、mock掉userService.getUserInfo()的返回值，传入构造好的参数调用方法，断言布尔结果即可，需要覆盖的场景包括：用户未登录无公司信息、传入的第三方公司id和当前用户公司id匹配、id不匹配三类。
• 测试noActiveAgreement时，同样不需要渲染，直接构造不同的request入参、控制amICo3pmCompany的返回值、mock钱包的强制第三方状态，覆盖所有判断分支：request无id、当前用户是第三方公司、request状态为INVITED/CONFIRMED、钱包状态为AWAITING_FUNDS、所有条件满足判定为无有效协议。
• 这部分测试运行速度极快，报错时可以直接定位到逻辑问题，不需要排查视图层的干扰，是性价比最高的测试部分。

模板层：只做绑定关系的校验测试 #

模板测试不需要重复穷举所有业务逻辑分支，它的唯一测试目标是验证类方法的返回值和视图渲染的绑定关系是否正确，你只需要覆盖3个核心渲染分支即可：

• spy组件实例上的noActiveAgreement方法指定返回true，断言页面渲染了atm-third-party-mandate-agreement组件，另外两个分支组件不存在
• 指定noActiveAgreement返回false、amICo3pmCompany返回true，断言页面渲染了atm-third-party-mandate-company-co3pm组件，另外两个分支组件不存在
• 指定noActiveAgreement返回false、amICo3pmCompany返回false，断言页面渲染了atm-third-party-mandate-company-c组件，另外两个分支组件不存在
• 这一步不需要再构造各种入参去走完整的业务逻辑判断——逻辑正确性已经在类方法测试中覆盖，模板测试只需要排查*ngIf条件写反、方法名拼写错误、模板引用指向错误这类视图绑定问题。

常见误区规避 #

不要走两个极端：

1. 只测类方法不测模板：很容易出现逻辑100%正确，但模板绑定写错导致线上渲染错误的问题
2. 所有逻辑都靠渲染后的页面断言：测试运行速度慢，报错后无法快速定位是逻辑错误还是绑定错误，测试维护成本极高

如果这类布尔判断逻辑会在多个组件中复用，建议抽成无副作用的纯工具函数单独测试，组件测试中只需要验证方法调用关系即可，进一步减少重复测试代码。

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