FED UI Testing & Refactoring 的痛点与反思

@JimmyLv 2017-06-16 07:50:59发表于 JimmyLv/jimmylv.github.io ⭐️⭐️===博客素材===⭐️⭐️

项目纵向拆分

前端UI级别单元测试的一些痛点:

  1. class name老变来变去的,依赖css selector的测试都得改
  2. UI styling根本没法测,多个少个px过分了
  3. 很多跨browser的hack,不同实现还得写不同测试cover?
  4. 响应式是个什么鬼?为什么天底下有这么多种不同分辨率的屏幕!?
  5. ……

又想起了大熊写的「重构已死」,讲的就是"重构本质乃是不改变软件可观察行为与功能"这个前提不再成立,因为软件本身就无时无刻随着需求的快速变化而改变,那何来不改变的软件行为呢?同理运用到测试上来说,需求老变化,每次都得改测试可烦了,PM/UX还没事儿跟你说这儿多个px,那儿少个icon之类的…

总之结论就是:TDD, 重构, 测试这些方法论运用在 后端业务需求,领域建模核心上来说很好使,这些东西也是从那时候开始发展而来…但是偏偏这个商业时代各种客户端UI层出不穷,需求变动也比以往大得多,很多APP都是周更新,那这些方法论也遇到了一些矛盾的地方

因此更讲究避免浪费吧,然后就来谈精益,🤣 所以我还是力挺TDD,而测试只是TDD的附属品。另外一个观点是:如果需求变动过大,我不如重新TDD实现一遍;而不是在原来的代码(&测试)基础之上进行重构。

需求变化,变化过快,这个真的会让测试带来的价值变少,甚至成为一种浪费吗?单元测试的输入,本身就是基于我们对设计和实现方案的假设,接口变了,需求变了,测试跟着变是当然的,只不过是假设的输入变了。说需求变了,因而测试价值减少了,因而原来就最好不写减少浪费,那变后的这些需求你又用什么来验证呢?还不是回到没测试裸奔手工验的状态。
我最近在开发,写好的单元测试,输入也是经常变,但原来的测试是不是就没有价值了?当然不是,测试挂掉的所有用例会帮我找出所有调用点。我不需要自己再去手动找,这个变的接口影响了哪些地方,我也不想找。把测试输入改成变后的需求,运行测试,挂掉的全部修好,然后再真实起应用跑,基本全是好的,就是不是,debug起来也很轻松。如果说抱怨测试经常要改输入改输出,那没有了测试接口需求变起来,验得岂不是更惨?
这段逻辑,主要说的是强逻辑强数据的代码段。ui方面,我觉得你说的痛点都存在,那种情况下,可能是自动化测试的成本,已经大过了手动验证或cdd的成本。「不改变的软件行为」,我觉得并不是指在一个月两个月内的软件行为都不变,而是你「重构前」和「重构后」的软件行为不能变

嗯 我都同意,特别是有明显输入输出和数据强相关的地方。而且你发现了没有,这也是React所带来的好处,哈哈哈,数据驱动和函数式思想(纯I/O),也让测试变得简单、单元化。衡量成本这件事情还是很难量化,感性得说,我还是不喜欢写UI测试…只写数据相关的测试会很爽,那么如果UI=f(data)这个等式在React中被严格实施的话,把data控制好测好,我觉得最终的UI也一定是好的,不测也罢。

上次看朋友圈有人吐槽Vue没法写测试,会心一笑 🙃

讲道理。我其实是并不赞同所谓的“测试”前端UI。如果像JSX这样的需要一次编译的,完全可以加强一下编译器,如果没有编译错误或者警告,就可以认为是正确的。

对呀,“如果UI=f(data)这个等式在React中被严格实施的话,把data控制好测好,我觉得最终由 jsx compile 出来的UI也一定是好的,不测也罢”

试问在什么情况下你的component里面会有复杂的业务逻辑导致你根本不能正确的写一段清晰的结构

组件的分类(Vue 作者尤大分享的 live):

  • 接入型 container
  • 展示型
  • 交互型 比如各类加强版的表单组件,通常强调复用
  • 功能型 比如 <router-view><transition>,作为一种扩展、抽象机制存在。(high-order component 高阶组件)

⓵ 定义目标和原则

⓶ 展望结果

⓷ 头脑风暴

⓸ 组织整理

⓹ 明确「下一步行动」