1
avenger 2019-05-15 16:39:38 +08:00 via iPhone
vue 可以用官方的 vue test utils 有案例
|
2
connection 2019-05-15 17:00:34 +08:00
交互性强 建议直接写 e2e
|
3
jun0205 2019-05-15 17:05:05 +08:00 via iPhone
写 e2e 吧,推荐试试 cypress.io
|
4
wu67 2019-05-15 17:34:37 +08:00 1
所以你们的项目都有时间写测试? 你们的项目都没产品经理改需求的吗
|
5
PainAndLove OP @avenger 嗯 看了,但是感觉案例有点简单,而且都是没有业务场景的组件。。 所以想知道如果结合业务场景,应该怎么样去写 ut
|
6
zhw2590582 2019-05-15 19:15:43 +08:00 via iPhone
我们前端从来不写单元测试,感觉写测试比写业务逻辑难
|
7
tinycold 2019-05-15 19:43:20 +08:00 via Android 3
别,别写 E2E,血泪教训。稍微一小点儿改动,你测试就挂了,而且 E2E 测试真的超级浪费时间,除非你们的 QA 足够专业并且他愿意来写并且维护。
一般我写代码前端单元测试,都是配合 Sinon 来做,用 sinon stub 一个组件对象,让后对组件对象的状态进行测试。 例如,一个组件有个跳转按钮,点击跳转按钮后先设置按钮为禁用,再调用一个 beforeLeave 函数,最后执行跳转函数跳转到另一个路由。那我会这么来写: 1. 先 stub 一个组件对象,然后手动调用它的生命周期初始化函数 2. 执行一次跳转按钮绑定的事件方法 3. 对禁用状态做断言 4. 对 beforeLeave 和跳转函数的 callCount 做断言 那么剩下的就是执行跳转函数后能否正确跳转到对应路由没测试了,再单独搞个 test case 来测试跳转函数就好了。 前端的需求变化是非常非常非常频繁的,如果写 E2E 测试,真的会逼死人。这样来写单元测试,能一定程度上保证健壮和可维护性,而且成本极低,框架无关,但是局限性很大。要是不考虑交付时间,那当然测试可以写得完美无比咯,但是真的值得吗 |
8
aleen42 2019-05-15 23:20:33 +08:00
这种东西能算是 FE 的 ut ?在我概念上,大部分 UT 应该是针对 functional libraries 的范畴(明确输入输出)。你这种像是属于自动化测试的一类?
|
9
minglanyu 2019-05-15 23:25:12 +08:00 via iPhone 1
写过一个 vue 的入门单测,https://segmentfault.com/a/1190000017225758
|
10
PainAndLove OP @aleen42 嗯 也可以这么说。 对组件的 UT 吧
|
11
zhuzhibin 2019-05-16 00:22:05 +08:00 via iPhone
前段时间小项目上了 cypress 对于 e2e 来说
项目变化太快 的确成本很高 |
12
KuroNekoFan 2019-05-16 08:28:47 +08:00 via iPhone
对于给定的输入有期望的输出,如果你的 ui 不带业务逻辑,那 ui 其实没啥好 ut 的,如果有,就把逻辑提取出来
总的来说成本很高 |