什么是驱动式的前端完美开发工作流？

[JimmyLv]

项目纵向拆分

哎，TDD写UI真是很无聊。

但是，结合 Storybook，我算是找到了比较完美的 UI+State 测试工作流，并且引入了 Storyshot，自动在UI完毕之后take Snapshot，然后就又发现了 image snapshot：

1. 先做组件设计， ref: http://reactjs.org/docs/thinking-in-react.html
2. 再撸 business logic 代码，纯函数 reducer 里面爽歪歪；action里面异步测试。
3. 再撸组件及其state，专注组件 JS logic 和 HTML 结构；
   -------------TDD结束；Storybook CDD 开始----------------
4. 先引入组件作为 Stories（纯HTML）
5. 再撸Styling，抽取StyledComponent
6. CSS写完，自动打个快照，截图对比！

https://github.com/storybooks/storybook/tree/master/addons/storyshots#configure-storyshots-for-image-snapshots--alpha-

卧槽，神器啊！！！！！直接给Storybook里面每个Components截图，然后做Snapshot testing

然后 左边 vs 右边，中间是 diff 的不同内容！我擦擦擦，真是很完美的方案了啊喂.

TDD business logic 就好，尽可能 pure component，然后组件样式什么的就直接CDD，在storybook里面看就好了。
反正还有 image snapshot 和 全局的 visual testing
截图比什么都来得快、来得直观

这个都可以删了啦，属于测细节了。测css是个错误的思路。
样式不用tdd啊～我觉得样式是个回归问题，它跟tdd关注点不一样，ui在于保证回归，而tdd在你出代码前要出结果。然而ui这事的视觉本质就导致用眼看比用代码快多了
Design System，组件库 + theme
首先，有这样一个组件库，然后所有的字体+颜色，等等都是可统一变化的。持续演进，可以多肤色，等等。样式改起来越容易，你就会经常改，用户体验就容易越来越好。

之前要在一个遗留代码库上做tdd其实很坑的
好比你练了红绿循环，信心满满要施展一把时发现，现有代码库分层不清，巨多没测试的逻辑在一起，巨多直接new import进来的依赖，
TDD 遗留代码就是个坑呀，import 直接全部 mock 掉。
spy都不想spy了，直接mock+stub想要的返回值，

⓵ 定义目标和原则

终极目的

Q：为什么你要花时间来做这项任务，而不是其他随便什么任务？
A：

⓶ 展望结果（OKRs）

利益相关人清单

Q：当你交付最终结果的时候，会如何让世界变得更好？
A：

⓷ 思维导图：头脑风暴/集思广益（发散）+ ⓸ 组织整理（收敛）

⓹ 明确「下一步行动」

能够产生反馈结果的小任务

[EthanLin-TWer]

你简直很高效…聊天记录直接上…太欣赏！

[JimmyLv]

前端需要兼顾的东西太多，先写什么后写什么真的很重要

而且需求变化，业务人员第一触及的都是前端，还得你来回答后端是否支持，由此多一层思考负担。

因此：

1. 先写html，因为样式最容易变，设计师喜欢改，有可能还没写样式，设计已经改啦 那就直接根据新样式改就行了
2. 再抽数据，即把会变化的数据从html里面抽回到js放到组件内，state或data里面，此时为常量。
3. 再写交互，这个时候，就是把2.中的常量变成变量，交互行为导致其变化，即行为的变化为常量。
4. 把行为变化进行抽象，再一次把变量变化分拆到redux或vuex的各处，同时处理异步。
5. 再写样式。

其中，第4.步的单元测试最为关键，而且input和ouput已经很明显

还有就是，整个过程很精益：

1. 虽然我数据是假的，但是我们让你看到东西呀
   2/3 你看我交互都有了，页面都能用起来啦！
2. 虽然我页面丑，但是我数据都是真实数据来自于后端哦
3. 我说的没错吧，优化用户体验，提升用户量

这儿我再给你加个动画，让你心情爽一hia

从工作流这个角度出发就更不那么喜欢react了，其实也不是不喜欢react，而是jsx。

又或者，jsx是否能带来更容易的插入式改进式实现呢？至少应该是更利于重构的。

v-if v-for 这样的directive其实更加适合演进式得添加交互和功能，改天拿实际需求来试试好了。😉

_{Sent with GitHawk}

[EthanLin-TWer]

我觉得第1点是最重要的，它重要点在于减轻 UI 变化对开发造成的影响。因为调样式是个成本不太低的事情（也可能跟技能有关系），如果布局、样式、交互这些不确定或因为其中一者而使得整体有改变时，之前调过的样式就全部拜拜了。而 UI 变化这个点在人眼看到实际的交互前不确定性强，这个根据实践经验确实是这样的。

[JimmyLv]

会跑步 会健身 会看书，咋就不集成呢，🤣

via [Write tests, not too many, mostly integration | Kent C. Dodds Blog]
https://kentcdodds.com/post/write-integration-tests/

假设：前端绝不应该过于追求 Unit Test，不要出现太多 Mock、Stub

甚至 Shallow Rendering，我之前有要求必须用浅渲染… 确实是有点过了 。 🤣

他这个测试一看就是后补的测试。。 many concerns

shadow rendering确实应该很慎用，依赖细节。

对组件来说，确实不需要关于依赖的子组件要做啥呀…

但它就算测自己，引入过多细节的话也很烦，一旦除了输入输出有其他因素会使测试挂掉，那这样的测试就不能支持重构，那就没用啊[捂脸]

你是说依赖的变化，也是（除输入输出以外）其他因素么？

像 find(selector) 这种，我觉得也算依赖了。你说子组件那个情况，因为被shallow render了，所以应该不会影响到？比如find('.brn-primary') 这种，我觉得就依赖于dom了，而这个好像是shadow render必用的的搭配[捂脸]

嗯，本质上 child component 就是依赖，如果在后端可能就是这样注入进去的：

new ComponentZ(new ComponentX(), new ComponentY()) ，然后可以在测试 ComponentZ 的时候把 Component 给mock了。

但是React里面没得（Angular有呀），而是 import 进来

import { ComponentX, ComponentY} from '@components'，在 xxx.test.js 里面也不好去mock一个Component了吧，因此才有了 shallow rendering 🤣

Angular里面是怎么处理 测试中的 components rendering 的呢？

angular简直就是后端的套路，di系统简直方便

👌， 抽组件 就是 抽依赖。组件即依赖。组件也是细节

angular中关于依赖…取决于你想不想测dom。angular依赖注入有两种方式，可以类比spring测试。一种是直接new作为参数注入，一种是起一个测试用的di帮你注入依赖

应该是，不需要关心 ComponentZ 内部的 ComponentY 和 ComponentX 依赖，即细节

所以结论可能是，好的测试策略：

1. 凡是跟DOM相关的，都应该集成测试、Mount Rendering，哪关心你有好多个子组件哟，给劳资跑起来就👌，能点击就👌
2. DOM应该是由 数据 render 而来的，DOM 行为也应该只是 dispatch action 而已
3. 其他数据相关的逻辑，才应该尽可能解耦，单元化。

组件作为单元测起来，没什么意义。

组件里有些逻辑我觉得，用尽可能健壮的shadow render去覆盖一下还是有意义的。

这么说来， 其实Snapshot 放在子组件层级才有意义，但是意义不大。而放到Integration层级，更加没有什么意义，因为整个Snapshot result会很大，没法diff或者diff很困难，也就会让Dev破罐子破摔，一股脑approve了，少去了验证的意义。

dom我理解有两个待测点，一个是集成起来的功能和交互，一个是样式。集成起来我觉得可以用集成和端到端去覆盖，着眼点也是功能，我的住流程跑的通不。测样式，感觉很多团队不必要用

嗯，我刚想说，不应该过于关注组件，而是应该是功能。

可以按照Feature来拆分组件，那按照feature来写测试，也会比单纯关注组件 把组件作为单元来测试 更加有意义。

是的咧，那么这个时候，还叫单元测试吗？

我感觉很多人用快照测试的动机就是我不会测试我不想测试我想一键完成好像很酷炫的样子，然后打完快照发现啥都没测到而且伤害了开发体验。

我不会测试，
我不想测试，
我不会也不想学测试，
我会也不想写测试，
我想但是不会测试。

很多人用快照测试的动机，可以有一个， 瞬间 100% 测试覆盖率！因为领导们，要求测试覆盖率必须上 90%。然后劳资 顺手一个 Snapshot 测顶层 App，就是丫的 100% 覆盖率。

const tree = renderer
    .create(<App />)
    .toJSON();
  expect(tree).toMatchSnapshot();

哈哈，这没问题，但用就用了，不要出来写博客噻。。据说兄弟项目组一天mock掉几十个依赖在顶层打了个快照，覆盖率瞬间50

原来 Angular就是这么玩的，看了Angular 的测试文档，头都大了。 https://angular.io/guide/testing#component-test-scenarios

看来就是有人很烦 Angular DI式的需要mock 各种子组件，反而偏爱 https://github.com/getsaf/shallow-render

组件和组件的依赖，如果不使用 Angular 的 TestBed，组件（view/template）是不会被测到的。我觉得 Angular 测试的毛病主要在它会真实地 compile 一下 dom 还是怎么样，DI 倒还好

那不使用 TestBed 就默认render所有子组件吧？

不使用 TestBed 就 new ArticleComponent() 然后就测上面的实例方法哩。。

不使用 TestBed 的话测不了DOM么？

是的，相当于你就只起了个 JS 函数来测

嗯，懂了，就是Component是Class，纯当class （即 JavaScript ）语境下来测

用 TestBed 毛病我觉得就是同时关注了 DOM 和组件逻辑。当然有人说这两者就是一个「整体」，一个「组件」但不可否认，你 DOM 改着改着单元测试就挂了额

嗯， 没毛病。 其实我觉得这样设计还挺好。

如果能配合上 E2E，把这部分 miss 掉的 DOM 按照业务价值覆盖一下就完美了

最近期望好好实践一下 E2E，在看 Cypress

我也发现现在我的短板是 e2e 啦，光有 ut 无法提升整体质量~

[JimmyLv]

#322

[JimmyLv]

测试驱动？ 测试在前端超弱的，你让我测 px 我会去撞墙的！怎么测功能和样式是不同的问题。
设计驱动？ 设计系统，讲的其实就是响应变化，如果 Sketch 能直接生成组件就好啦。
需求驱动？ 没有新需求，我直接 jQuery 撸也是很快的嘛！需求变化太大不如重写，何必搞得那么复杂。
组件驱动？ 先做组件，这可是公司的固有资产，有了组件就能轻易组合出页面，拖拖拽拽，想想就很美好？！