墨墨姐提示：这是一个神奇的帖子，产品经理转发给技术或是朋友圈，尽显你的专业！

在墨刀，我们一直在使用 web 前端技术开发各个平台的 UI 界面，其中包括我们的桌面客户端以及移动客户端。而墨刀本身又是个前端很复杂的产品，这也就暗示着 bug 不在少数，尤其是在产品经理和设计师的眼中，这些 bug 很有可能让他们感到抓狂，如果问题不断那么可能就会对墨刀弃用了。

交代一下之前的测试情况：

这次优化之前，我们是没有自动测试的，更多的是采用用户测试和内部测试的方式。随着人数的增加，每天提交的代码量也越来越大，原始的人工测试已经在拖着我们的工期，所以，引入自动化测试看来是非常自然的事情了。

最近我们已经搭建起了测试平台，工友们也在不断为自己的代码增加测试中，在保证产品稳定的同时，同样也提升了开发体验。我简单分享下我们是怎样选择测试框架的。

团队情况

首先，有必要说下我们目前的开发团队。目前我们有 7 名开发，还都很年轻，大多是刚毕业没几年，但充满激情。大部分是前端，专职后端只有一人（棒棒哒）。很多人也都是在过去的一年前加入，在产品快速成长中起了很重要的作用。

考虑重点

做决定往往很难，尤其是在现在的 web 前端中。光测试工具就有这么多种。

就像前面说的，由于我们的人员组成的特点，年轻，也有个弱点，就是经验不足，那么我们在做技术选型的时候，就特别看中社区，社区的发展状况直接决定了我们是否能够少踩坑。从另一方面来讲，公司仍处在创业阶段，每个人都是在产品前线上写代码，稳定的社区也能为我们省去了很多事，因为我们大多时候只要相信工具就好。

所以，面对众多的前端测试框架，现在的我们最看重的是社区氛围好坏，是否好上上手，和其他工具是否配合良好。当然，也是要有发展前景的，谁都不愿意在公司主要产品上成天换框架。

我们的选择

单元测试

现在去看Mocha、Jasmine、Jest、Ava这些流行的测试框架。同时考虑到我们的技术栈（React + Redux +Spine），我们最后选择了 Jest +Enzyme（嗯，越来越 Facebook 全家桶）。

第一次知道 Jest 是看了 Codecademy 讲述他们是如何测试 React 的文章，文中提到了 Jest 的缺点，慢，以及测试代码不能使用 ES2015 的语法等，最后他们选择了Karma+ Jasmine + Webpack + React。那时确实对 Jest 留下了不好的印象。但在这次对各种测试框架的尝试中，发现现在的 Jest 出奇的好。

除了解决了上述的问题外，Jest 与其他工具如 Babel、ESlint 的配合也几乎是无缝的，文档写得非常详细，几乎不带脑子走一遍就能在项目中跑起测试。

另外 Jest 是 Facebook 系，之前提到过，我们非常看重社区的支持，这点 Jest 完全可以满足我们的需求。

除此之外，墨刀在 UI 上很多地方用了 React，因此我们用了 Enzyme 来辅助测试 React 的组件。

用 Jest + Enzyme 来测试 component 大致是这样的：

速度上，带着 Babel ，Enzyme 的情况下，从 Setup 到 Teardown 总共耗时1.5s。目前来看，大量测试加入之后的性能还是未知，但从社区方面的反馈来看相信一定是可以接受的。

目前 Jest 是基于 Jasmine@2，所以 assert 语法是一样的，用过 BDD 的人都可以很好地过渡到 Jest。

Jest 还有很多很方便的功能，比如 Mock Functions，还有 built-in coverage report 等，都省去了很多单独配置的劳动。

除了对组件的测试外，我们也计划对数据层，Redux 的 reducer 写更多的单元测试。

端对端测试

由于 Jest 只能跑在 Node.js 上，虽然默认使用jsdom模拟浏览器环境（关掉 jsdom 会让 Jest 更快），但有些时候我们仍然需要在真实的浏览器中进行端对端测试，比如用户的登入，支付流程。因此我们引入了WebDriverIO+ Mocha +Chai+chai-as-promised在浏览器中进行基于流程的测试。这篇文章非常详细地介绍了怎样 setup 这些，这里就不再赘述。虽然这里又引入了 Mocha，但我们配置了 BDD 的语法，所以写起来几乎和 Jest 是很相似的。

开发流程

在开发流程上，我们目前在 CI 中只跑单元测试，在本地验证端对端测试。因为我们发现端对端测对性能要求还是有一定门槛的。另外即使是 PhantomJS，在 CI 上 setup 也不是那么容易。

----

希望借此文章和大家多多交流。

对于测试，我们才刚刚开始。