致Cypress：前端 TDD 的正确姿势到底是怎么样的？

重点研究一下 [Cypress](https://www.cypress.io/) 并实践 ATDD。

> 最近要重温html css js
> 意识到一个东西，tdd实践本身有可能确实不适用于前端大规模应用
> 它和后端的上下文还有不同

是的呢
而且为什么需要测试呢？
我指的是 测那么多技术复杂度没有意义呀？

> 只有小步迭代和快速反馈的核心是不变的

技术复杂度为什么要我们开发来测试呀？
比如说，REST API的测试，
少一个字段多一个字段，这种测起来有何意义？
为什么不能直接用直接让invoker来决定到底有多少字段

我就在想，有没有一种方式，让测试更有意义，测到该测的地方去。

而TDD也是一样的，对哪些内容该TDD，还是说所有东西都TDD呢？
还是Tasking+验证方式，最为关键。

至于验证方式，是不是UT，我觉得可以有更多讨论。

假如我们有秒级反应的CI作为流水线，
假如我们有秒级反应的AI作为“真实”用户，
那我每写完一行代码，立马CI构建出“真实”产品，然后AI帮我测完所有“真实”场景，然后给我一个反馈，是不是也很完美？

> 你的理解很准确啊，tasking加验证方式。验证方式这里，tdd以前在后端适用，我觉得离不开spring java这个上下文，完全的面向对象，我们现在的测试模型也多来自这里

嗯，Spring帮我们autowried，凡是依赖都可以mock掉
但其实js里面所有import也可以mock掉，🤣

> 对。但面向对象这个上下文在js里是不纯的

前端的反馈，我觉得还是不如搞个4屏吧

> 也就是说，前端ut在具体实践上需要更具体的指导，有些实践可能要弱化

哈哈哈，设计稿、Chrome显示页面、IDE、Chrome DevTool

> dev tool也要一屏卧槽

当然要呀，🤣
最好，devtool和file system连起来
试验CSS的时候可以直接save

> 哈哈哈哈
> 前端是重ui，交互，页面，布局的东西

> 我觉得提升前端工作效率 最需要着重的点
> 反而是 CSS 能力
> 这些东西复杂不在逻辑，反馈都是hot reload，跟tdd都没关系

CSS 阻碍了一切效率
尽管我优化查文档的效率可以达到秒级，但又有何用？还不是要查


看到一篇 e2e testing driven的文章
我觉得值得推荐下，[Learn TDD in Vue | Learn TDD](https://learntdd.in/vue/)

- [ ] 总结🥔测试开发经验