# 前端测试指东
都说测试重要,其实也重要也不重要,一个项目如果存在测试固然让人心安,但开发时编写测试花费的时间基本和开发时间等同,而节省测试时间,随便编出来的测试,可能还不如没有 此外,测试的范围种类会随着技术种类,作用业务去变化,换言之,测试的对象往往不固定,导致测试手段也要变化。可能只用测试纯函数,也可能要用到 dom,可能跟框架及其生命周期相关 再然后,测试用例是否应该单独管理,还是应该和项目中的模块绑定? 即存在如下问题
- 如何加速测试编写
- 如何确定测试对象及方法
- 如何管理测试用例 (实际上,我认为 tddbdd 之流无关紧要,想用就用,只是思路上的区别而已,但这两落实的时候的区别很重要)
# jest
就 jest 而言,有两种用法,一是基于函数的,就那种与视图无关,纯计算的函数(重要的功能函数,这个测试是一定要有的,次一类的工具函数也尽量要有) 二是基于组件的,这个其实功能比较局限,总结就是更改 props,内部 data,更改 slot,去看对应的影响,比如是否 emit 了什么,或者哪个类名变了,或者内部内容渲染改变了,哪个 dom 消失了 or 出现了 or 隐藏了(总而言之,就是当条件变化,出现对应结果,从而证明功能正确)
# storybook
storybook 现在用的人是真不算少,这玩意儿其实是有配套测试功能的,而且范围是惊人的广,基本什么功能都有,而且这些功能都不在 sb 里面,相当于都是解耦的 ,坏处同样,相当于要引入新的东西 (我记得前几天的 vue 大会上面好像出来了一个基于 vite 的类似 storybook 的东西,sb 的话,看它维护的情况以及相应插件的维护情况,以及基于 webpack 的糟糕效果,感觉可能不太会火很久) (我个人觉得 sb 这个东西原理上也真的不算难) 倒是其中一个功能有点意思,就是那个交互测试,说白了就是把测试中的操作行为,比如点击,放到 story 中,从而组件展示时自带交互效果,而且完全不影响原本的测试(即没有做新的东西,但却有新的效果 但如果对“更酷”这件事情没有追求的话,额,应该没啥用吧
# cypress
cypress 的话,因为组件具有逻辑功能和视图效果的,单元测试在视图上的效果不太好,即使可以模拟 dom,也不太好,因为测试通过与否,都不会意味 ui 上展示正确,尤其是没通过的时候,完全不知道视图究竟发生了什么,所以,这个层主要集中在交互造成的 ui 效果
粒度在往上一点,还有快照和视觉测试,前者我知道一些小工具能做,后者的话,额,有相应的服务网站,但技术的话,好像只有 pupeteer(只能用于 chrome 且体积巨大,npm 下载都会超时。。),html2canvas 或许也行?我不知道。 反正呢,如果组件有问题,大概率前两层(单元和 e2e)就遇到了,如果前两层没问题,这层有,大概率是各种兼容或者其他压根解决不了的问题吧。。不建议做这一层,快照或许可以弄一个默认的配置?我要再想想