关于 前端 单元测试 的问题。

[PainAndLove]

想请教一下各位大佬。 前端里和业务逻辑关系比较大的(react/vue)组件，有没有什么写 ut 的套路(规范)呢?

通过 give when then ?
还是 渲染 + 事件交互？

能给个 demo 当然最好啦
🙏谢谢

[avenger]

vue 可以用官方的 vue test utils 有案例

[connection]

交互性强 建议直接写 e2e

[jun0205]

写 e2e 吧，推荐试试 cypress.io

[wu67]

所以你们的项目都有时间写测试? 你们的项目都没产品经理改需求的吗

[PainAndLove]

@avenger 嗯 看了，但是感觉案例有点简单，而且都是没有业务场景的组件。。 所以想知道如果结合业务场景，应该怎么样去写 ut

[zhw2590582]

我们前端从来不写单元测试，感觉写测试比写业务逻辑难

[tinycold]

别，别写 E2E，血泪教训。稍微一小点儿改动，你测试就挂了，而且 E2E 测试真的超级浪费时间，除非你们的 QA 足够专业并且他愿意来写并且维护。

一般我写代码前端单元测试，都是配合 Sinon 来做，用 sinon stub 一个组件对象，让后对组件对象的状态进行测试。

例如，一个组件有个跳转按钮，点击跳转按钮后先设置按钮为禁用，再调用一个 beforeLeave 函数，最后执行跳转函数跳转到另一个路由。那我会这么来写:
1. 先 stub 一个组件对象，然后手动调用它的生命周期初始化函数
2. 执行一次跳转按钮绑定的事件方法
3. 对禁用状态做断言
4. 对 beforeLeave 和跳转函数的 callCount 做断言

那么剩下的就是执行跳转函数后能否正确跳转到对应路由没测试了，再单独搞个 test case 来测试跳转函数就好了。

前端的需求变化是非常非常非常频繁的，如果写 E2E 测试，真的会逼死人。这样来写单元测试，能一定程度上保证健壮和可维护性，而且成本极低，框架无关，但是局限性很大。要是不考虑交付时间，那当然测试可以写得完美无比咯，但是真的值得吗

[aleen42]

这种东西能算是 FE 的 ut ？在我概念上，大部分 UT 应该是针对 functional libraries 的范畴（明确输入输出）。你这种像是属于自动化测试的一类？

[minglanyu]

写过一个 vue 的入门单测，https://segmentfault.com/a/1190000017225758

[PainAndLove]

@aleen42 嗯 也可以这么说。 对组件的 UT 吧

[zhuzhibin]

前段时间小项目上了 cypress 对于 e2e 来说
项目变化太快 的确成本很高

[KuroNekoFan]

对于给定的输入有期望的输出，如果你的 ui 不带业务逻辑，那 ui 其实没啥好 ut 的，如果有，就把逻辑提取出来
总的来说成本很高