没有测试，在自测上花的心思、时间精力会更多些。
追求自测尽量 cover 全面，尽量减少 bug，减少在一些时候bug数被作为把柄的可能性。
在很多时候，写前端的端到端测试不可行，成本太高，所以需要策略提高人肉自测的质量。
本地环境自测：
一、从用户交互角度自测（黑盒测试）
cover 用户交互的排列组合进行测试 （用户交互复杂的模块，这里也会变多变复杂）
二、从代码角度自测（白盒测试）
1. 配置的修改：分析影响范围并排查验证
2. 组件的修改：
- 自己本身的验证：cover 用户交互的排列组合进行测试
- 看是否导致其他地方异常：用 go to references 去逐个排查验证
3. 方法的修改 （与组件的修改类似）
(2 与 3 时间充足的话可以考虑用上单元测试)
4. 即便是自己的项目，修改公共的配置或者方法与组件也要很谨慎，之后要仔细分析影响并验证
三、mock 数据问题
若本地环境某个接口实在无法返回类真实的数据（包括一直是 null 或者一直是 0），前端得做 mock 数据，提交的时候得注释掉 mock 相关代码。
自动化提醒检测方案：使用假数据时带上 `mock` 关键词，在 pre-commit 钩子里使用 check-mock 脚本，能在提交代码的时候帮忙把关。
代码实现：使用 check-mock 脚本自动检测提交代码里的 mock 关键词-CSDN博客
部署环境自测：
部署之后将修改的代码影响到的模块进行测试。
不同系统、不同模块本地环境与发布环境的差异点不一样，根据系统情况着重检查。
对于本人目前在做的系统的前端而言，部署环境与本地主要是数据不一样，对于一些图表，本地人肉 mock 的数据，不能保证其在真实数据的情况下展示完全没有问题。
标签：修改,前端,如何,测试,自测,交互,代码,mock From： https://blog.csdn.net/weixin_44278873/article/details/145296855