我如何在前端进行测试

2019 年 11 月 21 日下午 2:00（美国东部时间）我将在vuemeetup.com上进行演讲

这篇博文将探讨如何使用 Vue 进行敏捷开发，准备期间我构思了一些内容，但暂时没有时间一一讲解。虽然这篇博文原本是为 Vue 演示而写的，但其中没有任何内容是专门针对 Vue 的（这也是它未能入选的部分原因）。

为什么要测试？

在敏捷开发的背景下，测试的作用是给你信心，以便你可以更频繁地发布。

我对测试前端项目的看法是，我主要进行回归测试。

我不是在进行自动化测试以确保它符合票证验收标准，而是在编写测​​试以确保我刚添加的功能不会在某个时候停止工作。

当我刚刚添加一个新功能时，我通常知道它是否有效，因为我在编码时正在与它交互。所以，如果我为它编写测试，我很容易偷懒，编写的测试无法充分捕捉功能。如果我把测试看作是试图捕捉我所实现的功能，我会发现编写测试的工作会更容易一些。

我要写多少个测试？

最近有人问我，我会为一个（非特定）项目量化测试量。我很难给出一个简单的答案，因为这不仅是我的工作方式，而且每个项目的情况也有很大差异。

我有一个项目目前完全没有测试。我是唯一的（前端）开发人员，所做的修改范围从错误修复到我做过的一次重大重构。它主要是一个仪表板，影响变更的能力有限。但它不会很快发布，而且其中一些更改已经引起了重大变化，所以在 UI 功能完善或项目确定发布日期之前，我认为添加测试只是增加了一些开销，而这些开销我暂时可以节省时间/预算。最终，在发布之前，我会整理一组测试，以便我可以自信地发布并在发布后进行其他更改。

在另一个项目中，我进行了单元测试和集成测试。我甚至编写了一个脚本来比较视觉快照，以检查其在不同浏览器中的渲染效果。它运行起来需要一段时间，维护起来也很麻烦，但它可以捕获错误，每次它捕获错误时，我的多巴胺水平都会飙升。

我喜欢长测试名称

帮助我进行测试的还有编写看似不必要的长描述。

例如，当你的测试失败时，一年没有看代码之后，你希望看到哪种错误信息？

it('checks for existing email', () => {})
it('opens modal with error when user submits with an existing email', () => {})

未来的我不仅会感谢我发的那条荒谬的信息，而且我发现，当我以这种方式开始编写测试时，编写测试会更容易，因为我会记住自己在测试什么。在某些情况下，这些测试甚至可能来自工单的验收标准。

因此，如果我的测试读起来就像各种票证验收标准的历史记录，我就可以更自信地更改代码，第一次看到该项目的开发人员也可以这样做。

但我不喜欢快照

我最近决定远离快照测试（代码快照，而不是视觉/屏幕截图快照）。

我发现这些测试很容易编写。只需一行代码expect(myComponent).toMatchSnapshot();，就能确保 DOM 不会发生任何变化。然而，问题在于，这些测试中没有提供任何有用的断言。测试会显示差异，并突出显示哪些部分发生了变化，但由于缺乏上下文，你可能会花费大量时间来理解它。

我已经九个月没看过项目代码了，现在正在写一个新功能，快照测试失败了。快照测试失败是意料之中的事，因为我刚刚添加了一个功能，但我完全不知道快照测试到底在检查什么。盯着差异看了几分钟后，我以为一切可能都正常，于是就盲目地更新快照，让它在 CI/CD 流水线中通过了。那么，一个测试告诉你，当你修改了某些内容时，某些内容也发生了变化，它的价值是什么呢？花点时间写断言吧。

我会针对某些功能进行广泛的单元测试，比如测试电子邮件的正则表达式。但是，当你的集成测试要测试按钮时，对按钮进行单元测试似乎毫无意义。

我也很少做 TDD，因为在编写前端组件之前就先写单元测试的模式根本无法给我带来投资回报。在 CLI 或 API 服务器上，这很合理，但对于前端来说，这似乎太麻烦了。

图片来源：https://unsplash.com/@sarahmcgaughey