如何把测试带给团队？

前言

哈喽，大家好，我是海怪。

之前发了很多关于前端单测的文章，评论区里经常看到这样的留言：“最近也在搞前端单测…”。看来大家在给项目引入测试过程不是很顺利呀。当然我自己在引入测试的时候也有很多困难，
特别是面对那种庞大且完全没有测试的项目时，一时之间不知该从何入手。

Kent C. Dodds 这个老哥正好写了一篇关于 “如何在团队中引入测试的文章” 《How to add testing to an existing project》，
今天就把这篇文章分享给大家。

翻译中会尽量用更地道的语言，这也意味着会给原文加一层 Buf，想看原文的可点击 这里。

---

正片开始

相信大家都有这样的经历：当你在做一个 “不会上线” 的原型网页时，或许你可能连做原型的时间都没有，所以你肯定不会写测试。又或者你加入了一个从来没有写过测试的团队（也有可能只有你自己写测试）。

终于，有一天出了线上事故。在此之后，你每次要点 “发布” 按钮时总是心惊胆颤的。 同时，你还得继续写新需求和修 Bug，于是你受不了了，决定要给项目上测试，想要更高的代码信心。

但是，你该从何开始呢？

你的项目可能有上千、上万行代码，这个任务太大了以至于你连想都不敢想。但你总得从某个地方开始吧。好，现在让我们来仔细看看这个 测试模型，
看看上面哪些策略可以应用到你的项目。

下面就是整个测试模型，详情可以看这篇 文章。

当你准备开始时，可以优先关注高回报的部分。下面就是我们要做的：

第一步：配置静态检查工具

静态检查工具包括：

• Linter: ESLint
• 格式化: Prettier
• 类型检查: TypeScript / Flow

目前来说，配置 ESLint 是引入成本最低的方法了，它还可以帮你避免一堆的的错误。由于它的配置自由度比较高，你也可以增量式地引入到项目。
引入之后可以先把 Linter 规则设置成 warning 提醒，以后再慢慢把项目里有问题的代码改掉。

Prettier 也很容易配置，不过你可能要花点时间说服那些不喜欢用代码格式化工具的人。你可以看 《Why Prettier》 来了解它为什么这么有用。
我会把它归类为静态测试检查工具，因为如果你的代码里有语法错误，那 prettier 会格式化有问题的代码。

引入 TypeScript 和 Flow 可能会有点麻烦。当然，这俩也可以增量式地引入项目，但是配置它们以及要让它们在开发过程中能正常工作会花不少时间和精力。尽管这些工具也只是让 JavaScript 带有类型而已，但是也有一定的学习成本。

不过，我可以告诉你的是：这些静态类型检查工具是值得学习的。 我能给你的一个建议就是：不要在刚开始就要求项目有完美的类型定义。不要害怕用 any（或 known）！
它们可能在做类型检查时不是那么有用，但我见过很多人放弃 TypeScript 的一个原因是：他们花了很多时间去想怎么才能写好类型。
不完美就不完美吧，你可以在学到更多知识后再回过头来做更新迭代。

想了解更多关于静态测试工具的价值，详见：《Eliminate an entire category of bugs with a few simple tools》。

第二步：写一个简单的 E2E 测试

现在我们的目标就是从这个测试模型的底部走到顶部，这需要相当大的努力，同时回报也是巨大的。有很多种方法可以实现它，**最简单的方式就是写一个生产环境（或者一个类似生产环境的环境）的 E2E 测试，
用它走通最普遍/最重要的用户流程。**这个测试可能会写很长，但没关系（反正 E2E 写太短也是 常犯错误之一）。
不过，可以想象一下，如果你可以招了一个 QA，他可以在每次部署完都手动跑一次项目里重要的用户流程，那这多是一件美事呀，是非常有价值的。

这个 E2E 测试写起来不会很简单。 这取决于你的项目有多复杂，可能要一天或者几天才能在 CI 上跑上这个测试。如果你想用定时任务每一小时跑一下测试，也是可以的。就算你不能让它跑在 CI 上也没问题。可以慢慢迭代到最佳版本，不要让完美主义阻碍你的步伐。

第三步：写一个单测

我们再来看下一个测试类型。单测是最容易写的测试了。直接选项目里最简单的一个 纯函数 ，安装并配置好相应的测试工具，然后把它给测了。
一旦一个东西测成功了，那么写其它的测试就非常简单了。 很多人不写测试就是因为配置工具这块非常麻烦。所以你的工作就是要准备好工具（做好配置工作），让别人更容易地写测试。

第四步：写更多测试

到这一步，你应该已经准备好所有的工具和配置，可以写更多的测试了。现在可以把重心放在写更多的集成测试下面。
每一个测试你都会遇到新的挑战，你可能需要写一些模块的 Mock 实现。不过，当你做得越多，以后就越容易写测试。

你可能会发现有趣的是：到这一步我才建议你开始关注集成测试。虽然 它们通常会为你带来最大的收益 ，但是在测试工具还没配置好之前，集成测试是很难写的。
而且，相比于集成测试，第一次的完整 E2E 测试会更有价值。

第五步：教你的团队如何写测试

现在所有工具都已就位，你的团队就可以开始给项目代码写测试了。

（译注：后面都是作者对他的 TestingJavaScript.com 的宣传，我就不翻译了。关于这个课如何，我扫了一眼再结合这个人的文章来看，应该是不错的，不过价格属实有点贵。之后我应该也会买来看看，到时再做一波分享。）

总结

我希望这对你不断改进项目中的测试有所帮助。通过让人信心满满的测试策略，你晚上会睡得更好。😴 晚安。

---

好了，这篇外文就给大家带到这里了。这篇文章主要聊了一下如何把测试引入项目里，如果大家也在做同样的工作，可以参考一下这 5 个步骤。

我觉得写业务代码就像 C 位，做测试就像是打辅助。对于一个辅助来说不是疯狂奶队友，而是要针对目前的情况来决定要给谁奶，要复活谁，给谁资源。做测试是需要更全面了解项目的架构和功能的。

引入测试的一大难题往往是配置，很多人以为写测试就装一个 Jest 就开干，但我们项目往往会有很多 Tricky 的东西，这需要完备的配置才能支撑起测试环境。所以，文章里也说了：配置好了后，才能轻松写测试。

如果你喜欢我的分享，可以来一波一键三连，点赞、在看就是我最大的动力，比心 ❤️