介绍

主要改善体验

之前模式的问题

这套玩意儿我从年初就开始折腾了，当时主要的想法是做一个单独的工具，去生成测试的文件（在 nestjs 中就是产生接口文件），在整个过程中暴露的问题主要是两个，1：设计 dsl 2：转模板，这两很折腾人，原本想省力，结果反而更费力

分析

其实这一类（测试或者是近似的行为)主要是输入-输出的关系，以测试为例，需要一个数据 or 交互进行输入，然后再对输出进行断言。所以是要分为两部分去做，而不能直接去做模板

e2e

e2e 测试中，输入的东西主要是是模拟用户操作，如点击，而用户操作从本质上只有两类，即鼠标/键盘，那么这就存在把用户操作转为测试交互的可能（因为看上去工作量不大）！而在 web 中的话，鼠标点击并不是严格对应 click 事件，如 input 标签，其就会触发的是 focus 事件，所以同样需要一个映射

点击/键盘 --->click/focus(dom event) --->{type:"click"...}

所有转换形式的东西，只要一有中间对象就都好办了，就可以这样

点击/键盘 --->click/focus(dom event) --->{type:"click"...} ---> "cy.get("body").click(x,y)"（or memlab)

生成测试代码了，也即开发人员只需要自己操作一次，就能产出测试了，这做成一个chrome插件就很方便了 实际上没有那么简单，这里的映射规则会比较多，一点一点弄吧

unit

无论是对于组件的测试，还是函数测试，数据往往就是很纯粹的一个对象，这个对象无论如何是要自己编写了，但是！我们可以找一个编写过了的对象，比如，我在写组件，写函数的时候，在项目里的时候，我可能已经跑过这个组件/函数了,而跑的时候用的数据，在测试中完全可以重用！那这又是俩中情况，node/web,node的话暂时不考虑（如果要做，大概有监听输出流/require hook/显式记录这几种思路），web的话，即在开发过程中把对应数据记录下来，返回给服务端进行存储(和打包工具强结合咯)

断言

这个还是自己手写比较好，也算有点技术含量，如果可视化感觉会让操作变得很复杂