#323 added unit test table

前端/2019-05-08-vue-application-unit-test-strategy-and-practice-05-testing-trophy.md

@@ -43,12 +43,52 @@ published: True
 
 这种四层自动化测试提供了多快好省（放心、快速、省钱）的 JavaScript 专业化测试，最大的特点是它能够反复执行且收益递增，即不需要完全采纳就能获得收益，立马见效。
 
-### 性价比高的单元测试
+### 性价比最高的单元测试
 
 对于一个自动化测试策略，应该包含种类不同、关注点不同的测试，比如关注单元的单元测试、关注集成和契约的集成测试和契约测试、关注业务验收点的端到端测试等。正常来说，我们会受到资源的限制，无法应用所有层级的测试，效果也未必最佳。
 
 因此，我们需要有策略性地根据收益-成本的原则，考虑项目的实际情况和痛点来定制测试策略：比如三方依赖多的项目可以多写些契约测试，业务场景多、复杂或经常回归的场景可以多写些端到端测试，等。但不论如何，整个测试金字塔体系中，你还是应该拥有更多低层次的单元测试，因为它们**成本相对最低，运行速度最快**（通常是毫秒级别），而对单元的保护价值相对更大。
 
+## Vue 应用测试的测试策略
+
+![](https://miro.medium.com/max/1184/1*H9d9UQ4sVG9mQ3JIFzJW3A.png)
+
+一个常见的 Vue 应用会包括这么几个层面：组件、数据管理、Vuex、副作用等等，对于不同的项目应该有一定的适应性。Vue + Vuex 架构中的不同元素有不同的特点，因此即便是单元测试，我们也会有针对性的测试策略：
+
+|   架构层级   | 测试内容                                                     | 测试策略                                                     | 解释                                                         |
+| :----------: | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
+|  action 层   | 1. 是否获取了正确的参数<br />2. 是否正确地调用了 API<br />3. 是否使用了正确的返回值存取回 Vuex 中<br />4. 业务分支逻辑<br />5. 异常逻辑 | 这五个业务点建议 100% 覆盖                                   | 这个层级主要包含前述 5 大方面的业务逻辑，进行测试很有重构价值 |
+| mutation 层  | 是否正确完成计算                                             | 有逻辑的 mutation 要求 100%覆盖率                            | 这个层级输入输出明确，又包含业务计算，非常适合单元测试       |
+|  getter 层   | 是否正确完成计算                                             | 有逻辑的 getter 要求 100%覆盖率                              | 这个层级输入输出明确，又包含业务计算，非常适合单元测试       |
+| component 层 | 是否渲染了正确的组件                                         | 1.  组件的分支渲染逻辑要求100%覆盖<br/>2.  交互事件的调用参数一般要求100%覆盖<br/>3.  被 connect 过的组件不测<br/> | 这个层级最为复杂，还是以「代价最低，收益最高」为指导原则进行 |
+|    UI 层     | 组件是否渲染了正确的样式                                     | 1.  纯 UI 不测<br/>2.  CSS 不测                              | 这个层级以我目前理解来说测试较难稳定，成本又较高             |
+|   utils 层   | 各种辅助工具函数                                             | 没有副作用的必须 100% 覆盖                                   |                                                              |
+
+### Component 的测试标准
+
+组件测试其实是前端测试中实践最多，但各方看法最不统一的地方，这也是前后端在谈论单元测试时最大的分歧所在。Vue 组件是一个高度自治的单元，从分类上来看，它大概有这么几类：
+
+* 展示型业务组件
+* 容器型业务组件
+* 通用 UI 组件
+* 功能型组件
+
+对于 Vue 组件测什么不测什么有一些判断标准：除去功能型组件，其他类型的组件一般是以渲染出一个语法树 `render()` 为终点的，它描述了页面的 UI 内容、结构、样式和一些逻辑 `component(props) => UI`。内容、结构和样式，比起测试，直接在页面上调试反馈效果更好。测也不是不行，但都难免有不稳定的成本在；逻辑这块，有一测的价值，但需要控制好依赖。综合上面提到的测试原则进行考虑，我的建议是：两测两不测。
+
+* 组件分支渲染逻辑必须测
+* 事件调用和参数传递一般要测
+* 连接 vuex 的高阶 [SMART 组件](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0)不测
+* 渲染出来的 UI 不在单元测试层级测
+
+总结一下，其实每种组件都要测**渲染分支**和**事件调用**，跟组件类型根本没必然的关联…
+
+| 组件类型 / 测试内容 | 分支渲染逻辑 | 事件调用 | `@connect` | 纯 UI |
+| :-----------------: | :----------: | :------: | :--------: | :---: |
+|     展示型组件      |      ✅       |    ✅     |     –      |   ❌   |
+|     容器型组件      |      ✅       |    ✅     |     ❌      |   ❌   |
+|    通用 UI 组件     |      ✅       |    ✅     |     –      |   ❌   |
+|     功能型组件      |      ✅       |    ✅     |     ❌      |   ❌   |
+
 ## 单元测试的 F.I.R.S.T 原则
 
 编写容易维护的单元测试有一些原则，这些原则对于任何语言、任何层级的测试都适用。这些原则不是新东西，但总是需要时时温故知新，前人总结成 F.I.R.S.T 五个原则，以此为镜，可以时时检验你的单元测试是否高效：