本文首发于
欢迎关注（凡可 JavaScript，终将 JavaScript。）
欢迎关注我的，，，。
前言
本文主要尝试解决三个问题：
- 在 TDD 做完Tasking列完实例化数据之后，完全没有UT基础不知道该怎么写单元测试？
- 在Vue应用的单元测试中，对UI组件和vuex store等测试的区别有何不同？颗粒度该细到什么程度？
- 测试收益如何最大化，如何配置高性价比的测试策略，即什么地方到底该花力气测试，什么地方又可以暂且放一放？
不谈论的包括：
- ATT 验收测试 或 E2E 端到端测试，这个是我想进一步探索的话题，特别是在TDD的语境下。
- 为什么要 TDD？但是我会讲为什么要 UT 单元测试。测试和TDD是两码事，而光是自动化测试的好处就已经足够多，但是如何做到更好的自动化和持续集成，那就需要TDD来指引方向。
- Snapshot Testing 快照测试，其实我是很认可快照这种形式，但需要改进其工作流，至少结合Image Snapshot和Storybook等工具，甚至更应该放到CI上去。
下面我就来结合具体场景，进一步实例化这些问题，举几个?：
- 在 TDD 做完Tasking列完实例化数据之后，完全没有UT基础不知道该怎么写单元测试？
// Given一个完全没有UT基础的新人?// When当他?阅读和练习本文的Jest的部分// Then他能够把Given/When/Then的套路学会他能够学会Jest的基本用法，包括测试suite和断言等语法他能够学会Jest中测试异步的几种方式复制代码
- 在Vue应用的单元测试中，对UI组件和vuex store等测试的区别有何不同？颗粒度该细到什么程度？
// Given一个有基本的UT知识但没写过Vue测试的新人?// When当他?阅读和练习本文的Vue单元测试的部分// Then当然，他能够学会Vue组件在测试当中的几种渲染方式他能够学会UI组件的分类，特别是交互行为的测试方式他能够对Vuex概念的理解更加深入，且知道 `Redux-like` 架构的好处他能够合理测试vuex store的mutation和getter中的业务逻辑他能够测试组件如何正确dispatch action以及action中如何做异步操作复制代码
- Vue项目中测试收益如何最大化，如何配置高性价比的测试策略，即什么地方到底该花力气测试，什么地方又可以暂且放一放？
// Given一个具备UT基础但找不到着力点的求索之徒?// When当他?阅读本文的Vue应用测试策略部分// Then他能够找到测试的重点，重新燃起对UT的热情?他能够在项目背景下合理配置单元测试的测试策略复制代码
于是乎，这就是本系列文章的大纲，先放出来给大家一个对于Vue应用单元测试的全局观：
## 单元测试基础### 为什么选择 Jest### Jest 的基本用法### 该如何测试异步代码？### 单元测试与自动化的意义## Vue 单元测试### Vue 组件的渲染方式### Wrapper `find()` 方法与选择器### UI 组件交互行为的测试## Vuex 单元测试### CQRS 与 `Redux-like` 架构### 如何对 Vuex 进行单元测试### Vue组件和Vuex store的交互## Vue应用测试策略### 单元测试的特点及其位置### 单元测试的关注点### 应用测试的测试策略复制代码
? 哦豁，正文终于开始……
为什么要有单元测试？
引用鲜明的观点就是：写不好是能力问题，不写则是态度问题。单元测试客观上可以让开发者的工作更高效，Vue 应用的单元测试是一定要的。
单元测试的上下文
谈任何东西都一定要有个上下文。你的论述不能是「因为单元测试有这些好处，所以我们要做单元测试」，而应该是「不做单元测试我们会遇到什么问题」，这样才能回答「为什么要写单元测试」的问题。那么我们谈论单元测试的上下文是什么呢？不做单元测试我们会遇到什么问题呢？
上图为一个产品从 idea 分析、设计、开发、测试到交付并获取市场反馈的过程。
而单元测试的上下文就是存在于「敏捷」当中。敏捷为的是更快地交付有价值的可工作的软件。为此，它有一个指标来度量这个「更快」，那就是 lead time，它度量的是一个 idea 从提出被验证，到最终上生产环境面对用户的时间。显然，这个时间越短，软件获得反馈的时间就越短，对价值的验证就越快发生。
单元测试的意义
这个结论对我们写不写单元测试有什么影响呢？答案是，不写单元测试，你就快不起来。为啥呢？因为每次发布，你都要投入人力来进行手工测试；因为没有测试，你倾向于不敢随意重构，这又导致代码逐渐腐化，复杂度使得你的开发速度降低。
那么在这个上下文中来谈要不要单元测试，我们就可以很有根据了，而不是“开发爽了就用，不爽就不用”这样含糊的答案：
- 如果你说我的业务部门不需要频繁上线，并且我有足够的人力来覆盖手工测试，那你可以不用单元测试
- 如果你说我不在意代码腐化，并且我也不做重构，那你可以不用单元测试
- 如果你说我不在意代码质量，好几个没有测试保护的
if-else裸奔也不在话下，脑不好还做什么程序员，那你可以不用单元测试 - 如果你说我确有快速部署的需求，但我们不 care 质量问题，出回归问题就修，那你可以不用单元测试
除此之外，你就需要写单元测试。如果你想随时整理重构代码，那么你需要写单元测试；如果你想有自动化的测试套件来帮你快速验证提交的完整性，那么你需要写单元测试。
单元测试与自动化的关系
综上，我们用来谈论单元测试的「透镜」是什么呢？一言以蔽之，两点：反馈速度和自动化。
自动化回答的是要不要自动化的单元测试这个问题。测试是重构的唯一保障，也就是说，没有测试，基本上就没法重构代码（重构指的是 ），基本上就只能看着代码腐化。那么，基本上只要你的系统需要持续发展，你就需要单元测试。
反馈速度回答的是要不要 TDD、测试先行还是后补这个问题。答案是，需要 TDD，最好先行，因为，缩短反馈周期，与此同时减少不必要的浪费。
至此，回答了「为什么我们需要写单元测试」的问题。下面让我们来谈谈如何写好 JavaScript 代码和 Vue 应用框架的单元测试。
如何选择一个测试框架？
众所周知，JavaScript 世界里最不缺的就是轮子，测试框架也是如此。其实这里的子标题就是为什么选择 Jest？有时候安于现状，只不过是因为我们没有见过理想的模样。只有当我们见过更好的世界和更好的测试框架，才会惊呼“原来世界是这样美好呀！我怎么都没有想到呢？”
引自：Jest是一个“零配置”的前端测试工具，具有诸如模拟和代码覆盖之类的开箱即用特性，主要用于React和其他JavaScript框架。
我们团队对采用JEST做前端测试的结果非常满意。它提供了一种“零配置”的开发体验，并具备诸多开箱即用的功能，比如 Mock 和代码覆盖率等。你不仅可以将此测试框架应用于React.js应用程序，也可以应用于其他 JavaScript 框架。Jest 经常被炒作的功能之一是用户界面的快照测试。快照测试可以作为测试金字塔上层一个很好的补充，但请记住，单元测试仍然是坚实的基础。
一个好的测试框架，Jest 的几大好处可以涵盖为：
- Fast 天下武功，唯快不破。确实很快，虽然实测下来跟 还是慢了些，以后找个机会再测一次。
- Opinionated 不需要你做出选择和配置，就能提供所有的东西，比如Mock（干掉Sinon）、Test Runner（干掉Karma）、Matcher（干掉Chai）、Test Coverage（内置istanbul）
- Watch Mode 守护模式。非常注重开发者体验，能够在编码的时候帮助我们快速获得测试结果的反馈。
- Snapshot Testing 快照测试。这是值得争议的一点，前文也提到过会专门开个issue来讨论，在此不再赘述。
最后，总结一下 Jest
Jest 作为一个测试框架，其最大的特点就在于它是一个非常有效的解决方案，不需要与其他测试库交互来执行它的工作。与此同时 Jest 非常注重，这一点也是特别值得欣赏，现在市面上关注开发者（“人”）体验的开发框架和工具实在不多，而Jest Watch模式的核心就在于快速获得反馈，虽然我没在命令行使用而是WebStorm但亦可以与之结合。
ps: 除此之外，还有很多开发者体验亦值得细细品味与发现，特别是Jest本身来自Facebook的工程化支持也是特别棒的，这个讲述如何开发Jest的官方视频值得一看：。
未完待续……
## 单元测试基础
- [x] ### 为什么选择 Jest
- [ ] ### Jest 的基本用法
- [ ] ### 该如何测试异步代码？
- [ ] ### 单元测试与自动化的意义
## Vue 单元测试
- [ ] ### Vue 组件的渲染方式
- [ ] ### Wrapper
find()方法与选择器 - [ ] ### UI 组件交互行为的测试
## Vuex 单元测试
- [ ] ### CQRS 与
Redux-like架构 - [ ] ### 如何对 Vuex 进行单元测试
- [ ] ### Vue组件和Vuex store的交互
## Vue应用测试策略
- [ ] ### 单元测试的特点及其位置
- [ ] ### 单元测试的关注点
- [ ] ### 应用测试的测试策略