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

@JimmyLv 2018-07-20 12:14:04发表于 JimmyLv/jimmylv.github.io

重点研究一下 Cypress 并实践 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

  • 总结🥔测试开发经验