成为 JavaScript 测试专家：14 个面向开发人员的资源

你知道我对测试充满热情。测试帮助我维护良好的代码设计，专注于代码的目的，并防止将来出现回归问题。

我一直（现在仍然）投入大量时间探索 JavaScript 测试的精髓，尝试各种方法和技术，力求达到最佳效果。
过去一年，我决定记录我的旅程，并通过我的博客与大家分享。博客里记录了所有精彩的细节：我的经历、克服的障碍、取得的突破、发现的工具、汲取的教训等等。

我一直在囤积 JavaScript 测试资源，就像松鼠囤积橡子一样。不过别担心，我终于把最近发现的所有资源都整理到一起，供大家参考，每篇都附有内容概要和查看链接。整理的时候，我发现自己拥有的内容比预想的要多（我可能对测试有点痴迷），不过别担心，我精心挑选了精华内容供大家欣赏。

享受！

1.使用 React Testing Library 测试简单组件

好吧，我得承认，测试已经构建好的组件并非我最喜欢做的事情，但有时它恰好是医生建议的。在本文中，我将带您逐步体验测试现有组件的旅程。我们将使用React Testing Lib进行一些复杂的 React 单元测试，模拟用户交互并尝试不同的断言技术。最后，我们甚至会运行一份测试覆盖率报告来查看我们的测试效果，并向您展示当您的组件完全覆盖时，重构将变得多么轻松。

链接：https ://dev.to/mbarzeev/testing-a-simple-component-with-react-testing-library-5bc6

2.使用 TDD 创建 React 组件

女士们，先生们，快来见证测试驱动开发的魅力吧！在本文中，我将使用 TDD 方法创建一个 React 组件。我们将从一张白纸和一份需求列表开始，然后，首先编写测试，观察测试失败，编写代码使其通过，然后进行重构，最后处理下一个需求。
我知道这不是创建组件的典型方法，但它确实是一种令人振奋的体验。读完这篇文章，你将看到 TDD 可以应用于 UI 组件，而且相当容易。

链接：https://dev.to/mbarzeev/creating-a-react-component-with-tdd-2jn8

3.使用 React Testing Library 修复错误

让我们先来现实一点，我们的代码里都有 bug，这是生活中的常态。在本文中，我将处理一个难以捉摸的 bug，并使用测试来追踪它，就像侦探追踪嫌疑人一样。一旦我找到了罪魁祸首，这些测试就如同一张安全网，让我可以修复它而不会引入新的问题。既然我们已经处于测试模式，为什么不也测试一下 Redux 的状态呢？当然可以！

链接：https ://dev.to/mbarzeev/fixing-a-bug-using-react-testing-library-3hmh

4.使用 TDD 创建 React 自定义 Hook

在本文中，我将带您踏上使用 TDD 方法创建自定义钩子的旅程。我们将首先定义钩子的需求，然后编写测试，观察测试失败，编写代码使其通过，并在进入下一步之前进行一些重构。
我还将使用@testing-library/react-hooks 库，它允许我“渲染”一个钩子并对其执行断言，这非常简洁。所以，让我们一起来看看，如何使用红绿重构方法，一步一步地将这个钩子变成现实。

链接：https://dev.to/mbarzeev/creating-a-react-custom-hook-using-tdd-2o

5.使用 MSW 进行自定义 Fetch React Hook 的 TDD

这篇文章的灵感来自我上一篇文章（评论对我来说就像金子一样珍贵！）的一条评论，它挑战我将 TDD 应用到服务器获取钩子上。接受挑战！
我将使用MSW（模拟服务工作线程）来模拟 API 调用进行测试，这很酷。要求很简单：从 URL 获取数据，指示获取状态，并使数据可供使用。从这里开始，我们将沿着“红-绿-重构”方法论的狂野之旅，直到我们到达终点线。系好安全带，享受这场精彩的演出吧！

链接：https ://dev.to/mbarzeev/tdd-with-msw-for-a-custom-fetch-react-hook-485c

我们已经完成了 JavaScript 测试，现在是时候进入 linting 的世界了。在本文中，我将使用 TDD 方法创建一个简单的 ESlint 规则。
该规则将确保开发人员无法从某些模块导入命名空间（“import * as ...”），并可以选择将其配置为禁止从某些模块导入命名空间。
为了测试该规则，我将使用RuleTester，这是一个用于编写 ESLint 规则测试的实用程序，它非常出色。RuleTester 提供了一种不同的批量断言方式，令人耳目一新。

链接：https ://dev.to/mbarzeev/creating-a-custom-eslint-rule-with-tdd-120g

7.汇总所有 Monorepo 软件包的单元测试覆盖率

在本文中，我将向您展示如何为我的Pedalboard Monorepo添加汇总的单元测试代码覆盖率报告。Monorepo
可能有点繁琐，包含许多包，每个包都应该包含测试，并且需要生成代码覆盖率报告。但是，如果您想要一个可以一目了然地查看整个 Monorepo 的整体覆盖率状态的地方，该怎么办？
那么，本文将向您展示如何做到这一点 :)。

链接：https ://dev.to/mbarzeev/aggregating-unit-test-coverage-for-all-monorepos-packages-20c6

8.为什么在测试中践行 DRY 对你有害

这篇文章与我最近发表的文章略有不同。我将分享我对在单元测试中践行 DRY 原则的看法，以及为什么我认为这是一个糟糕的主意。你同意吗？

链接：https ://dev.to/mbarzeev/why-practicing-dry-in-tests-is-bad-for-you-j7f

9.从 Jest 到 Vitest - 迁移和基准测试

在本文中，我将挑战一个新的挑战者——一个引起我注意的测试框架——Vitest。我将把我项目的测试运行器框架从 Jest 迁移到 Vitest，看看它是否真的名副其实地宣称自己是一个“超快的单元测试框架”。
迁移过程并非一帆风顺，但我最终还是成功运行了它。希望我的这些经验和解决方案能帮你节省几分钟甚至几个小时。它真的更快吗？你得亲自体验一下了 ;)

链接：https ://dev.to/mbarzeev/from-jest-to-vitest-migration-and-benchmark-23pl

10.为什么事后测试是不好的做法

我得坦白说，我也是事后测试的，我承认 :) 但我真的尽量避免这样做。
在本文中，我将阐述为什么在所谓的“可运行”代码完成后再编写测试是一种不好的做法。这就像在正餐前吃甜点，很诱人，但绝对不是正确的做法。

链接：https ://dev.to/mbarzeev/why-testing-after-is-a-bad-practice-2pj5

11. Jest Mocking 备忘单

我知道，在 Jest 模拟方面，我并不孤单——每次都像记住一个一年只打一次的电话号码一样，根本记不住。但我厌倦了每次都搜索相同的代码片段，所以我决定自己动手，创建一个 Cheatsheet，记录我所知道的那些难以捉摸的模拟代码片段。希望它也能帮你节省一些时间，让你能像专业人士一样使用它进行模拟！

链接：https ://dev.to/mbarzeev/jest-mocking-cheatsheet-fca

12.使用 Vitest 测试 SolidJS 组件

在本文中，我将在一个 SolidJS 项目中引入 Vitest，并测试其中的一个组件。我知道，我知道它有一个项目模板，但那还有什么乐趣呢？我想了解如何在现有的 SolidJS 项目中包含 Vitest 单元测试，所以我将从头开始，添加所需的依赖项和配置。但请注意，这不是一个适合胆小者的旅程…… ;)

另外请确保检查此更新：https://dev.to/mbarzeev/update-testing-a-solidjs-component-using-vitest-1pj9

链接：https ://dev.to/mbarzeev/testing-a-solidjs-component-using-vitest-2h35