作者：郭永峰，前端架构师，现用友网络 FED团队负责人，目前主要负责企业级应用前端技术平台建设工作，在前端工程化实现、Node 应用开发、React技术、移动开发等方向有丰富实践经验。Github地址：https://github.com/GuoYongfeng。
使用 React + Redux 这个技术栈开发应用已经有很长一段时间了，我的一些使用经验也许会有些主观，但我觉得写出来也许对你开始学习或是进阶使用 React + Redux 会有些帮助。Redux 并不是只和 React 结合使用的，它也可以和其他的很多类库结合起来一起使用，即使你还未开始深入使用，你也可以阅读文中的部分内容。同时，如果你有一些建议或是疑惑，可以在 Github 给我提交 Issue，很乐意与你一起交流。
本次分享共有三篇文章，本文为第三篇（其余两篇，请点击阅读原文查看）。
关于测试的一些学习建议
我们可以组合使用一些测试工具来帮助测试 JS 代码，一般使用 Mocha/Chai 或是 Karma/Jasmine 。而如果当你想测试 angular 的代码时，你会发现还有更多的测试工具。不过对于 React 应用的测试，比较推荐使用 Airbnb 团队出品的 anzyme 来进行组件的测试，以保住组件的稳定可靠，目前使用非常广泛；而另一种方式是使用 Facebook 的 jest 来进行测试。
可能很多同学都觉得应该选择以上的某一个测试库来进行测试工作，不过，你也可以将 anzyme 和 jest 结合起来一起使用。特别是在进行一些 snapshot 快照测试的时候，两种都是互补的，它们已经是 React 应用测试中大家公认的标准库了。
sinon 也是个非常优秀的测试辅助工具，可以帮助我们在 spy、stub、mock 等测试阶段提供相应的工具辅助测试。如果对这几个概念不太清晰，可以看看这里：http://sinonjs.org/。
另外，在这里给你隆重的给你推荐一篇 A. Sharif 写的 Some Thoughts On Testing React/Redux Applications，满满的干货分享哦。
多一些组件的单元测试，少一些集成测试
Enzyme 可以帮助我们实现组件的单元测试和集成测试。这里我们可以通过三种方式来渲染组件：
shallow() 只能用来渲染不包含 children 的组件，mount() 则能够渲染所有的子组件。所以单元测试的时候可以使用 shallow() ，mount() 则一般用于集成测试。集成测试往往是很容易被割裂的，因为他需要测试由一组或是多个组件树组合的场景，所以集成测试一般维护成本是比较高的。所以我们可以多做一些小巧的单元测试，少做一些重要的集成测试。
第三种测试的方式是使用 render() 方法，具有类似 mount()方法的功能，不过 mount() 能够访问到组件的生命周期方法，比如 componentDidUpdate等。
正如这个 issue 中提出的 API differences between render and mount/shallow，可以总结出：
保证测试用例简单、最小颗粒度
否则的话你需要为此付出很高的维护成本。
确认每个组件是否都有执行过单元测试，确认每个 props 和 callbacks 都在集成测试的时候传递给了对应的子组件。
为了保证组件测试用例的小颗粒度和简单化，你需要熟悉一下 selectors，Enzyme 提供了丰富的 selector 去深入组件树。
另外，建议使用 sinon 来测试 callbacks 回调函数，不要在组件中测试业务逻辑，这真不是个好注意。而是应该将业务逻辑从组件中解耦并对其进行测试。
最后，Facebook 出品的 Jest 也能在初期帮助我们更加轻量的执行测试，你可以非常简单就设置好 snapshot test，这样当组件的输出改变的话测试用例会自动的报出失败的结果，并且能够获取到错误信息。
拥抱 TDD（测试驱动开发）
所有的人都可能会对你说：你应该按测试驱动的模式来进行开发。但是，几乎没几个人会这么，项目需求如山的积压，上线的脚本火急火燎，测试驱动？玩呢？！可能大部分小伙伴都是这样的心声。
不过，如果你能够清晰的在 React + Redux 的应用中使用对应的测试方案对每个部分都进行测试，你就能够非常轻松的实现 TDD。尽管你会发现 reducer 的测试和组件的测试是很不一样的，但其实每种类型（reducer、component…… ）的测试模式其实都是一样的。
就拿 reducer 的测试为例吧，一般是期望 reducer(state, action) === newState，其实这种方式和 (input) => output 的模式是一样的。如果你要测试 state 的不可变性的话，建议你可以使用 deep-freeze，可以看下以下示例代码：
import deepFreeze from 'deep-freeze'const initialState = { ... };
const action = { type: ..., payload: ... };
const expectedState = { ... };
deepFreeze(initialState);
expect(reducer(initialState, action)).to.equal(expectedState);
如果你能够很清晰的知道如何测试应用中的每一个部分，那就最好采用 TDD。
多组件测试
关于资源加载的选择
React 虽然是个 library，但是它的生态圈非常的丰富，会有非常多的可扩展框架或类库可以加入使用，但是千万别太快的加入这些扩展方案。并且每次新加入一个模块的时候，要在团队里面确认每个人都是清楚了解的。特别是对于 Redux 本身的一些生态扩展，会有非常多的一些小模块，比如下面这些：
在大家还没开始写 action creators 和 reducers 之前，就不要添加 redux-actions；
在大家还没写出第一个自己的 form 表单和表单验证的时候，就不要加入 redux-form；
在大家还没开始写自己的 selectors 之前，就不要加入 reselect；
在大家还么开始写第一个高阶组件 HOC 之前，就不要加入 recompose；
…..
同时，关注一些大牛的最佳实践，并且建立你自己的最佳实践。不过得确保团队中其他小伙伴也能理解。定义清晰的命名规则和目录结构，并且在项目做一些升级的时候得把这些约定提前讨论清楚。
保持持续的技术学习热情
关注技术社区的新动向，比如在应用中使用 ramda.js.，看看如何在React中优雅的写代码；
学习如何使用 React Native 构建你的移动应用；
学习使用 Electron 构建你的桌面应用；
也许你可以关注如何使用 Mobx 来进行应用状态管理；
React 仅仅只是 UI 层的一个 library ，你可以使用PREACT 和 inferno 等类似 React 的库来替代，他们的体积能加轻量，渲染更加高效，也许是个不错的选择；
Airbnb 的 React/JSX 规范 我也建议你抽时间看看，对于团队一致化开发非常有帮助。同时，也可以使用 ESLint 来进行代码规则检查。
该系列的上篇、中篇请点击阅读原文查看。
