Thomas Ladd 发布了一篇关于他们前端团队如何进行测试的不错的文章。 这些清单感觉是一个不错的起点。
- TypeScript – 一种语言，但您基本上可以免费获得各种测试（传递正确的参数和变量类型）。
- Jest – 单元测试。 JavaScript 函数执行正确操作。 适用于 React。
- Cypress – 集成测试。 页面加载，对页面进行操作，DOM 中出现预期结果。 Thomas 说，他们的端到端测试（例如，访问服务）也使用 Cypress 完成，并且没有对数据进行模拟。
我认为这反映了现代设置在许多前端团队中的应用。 如果需要添加任何内容，我认为视觉回归测试（例如，使用 Percy 等工具）将是需要添加的内容。
作为 Cypress 的替代方案，jest-puppeteer 也值得一提，因为 (1) Jest 已在此处使用，并且 (2) Puppeteer 可能是控制浏览器的更直接方法——没有中间语言或 Electron 或任何其他东西。
Thomas 甚至写道，这里有一个缺点：工具过多。
我们不仅需要了解如何在这些不同的工具中编写测试；我们还需要始终做出关于使用哪个工具的决策。 我应该编写一个涵盖此功能的 E2E 测试，还是编写一个集成测试就足够了？ 我是否还需要单元测试来涵盖其中一些更细粒度的细节？
毫无疑问，如果只有一个选择，这里就会存在心理负担。 一般来说，我们首先将集成测试作为默认选项，然后在感觉功能特别关键且依赖后端时添加 E2E 测试。
我不确定我们是否能够达到只编写一种测试的程度，但让单元测试和集成测试共享一些通用语言是很好的。 从理论上讲，我的结论也正好相反：集成/E2E 测试是更好的默认选项，因为它们更接近现实，并且只需测试一项内容即可证明大量内容是正确的。 它们应该是默认选项。 然而，它们也更慢且更不稳定，所以令人沮丧。