我的职业生涯初期几乎没有写过单元测试 。刚开始做 java，在一个国内银行的外包项目组，经理天天都在催进度，测试是不可能测试的。后来做前端，虽然摸索着写了点 nodejs 的测试，研究了 TDD 。但是前端页面是不让测试的，按照我们leader的说法，页面测什么测，不如直接上了，让用户帮我们测。 大概两三年前，进了现在的组，所有的 PR 都要 build pass，而 unit test 是 build pipeline 的重要一环，于是不得不学着写测试。只是这么一写就没法停下来了 -- 是公司没法停下来了，我肯定是不想写的，多一行代码都不想写（😂）。本来就写业务代码而已，现在好了，写了代码还要写测试，改了代码还要改测试。烦死了 。 然后就了解到了 snapshot 测试。

snapshot 测试是个啥

单元测试的核心思想是判定预期输出和实际输出是否相等。举个简单的例子：函数 sum(a, b) 的预期输出是 a + b，那么我们就写一个测试用例，输入 1 和 2，预期输出是 3，然后运行测试，如果实际输出也是 3，那么测试通过，否则测试失败。 snapshot 是一种特殊的测试方法，它会把函数的输出保存下来，作为一个 snapshot 文件。当我们第一次运行测试时，snapshot 文件会被创建，并且保存了函数的输出。以后每次运行测试时，snapshot 文件会被读取，并且和函数的实际输出进行比较。如果两者不相等，那么测试失败，否则测试通过。

为啥说它是个神

一般测试，输出（output）是需要自己管理的。比如 expect(sum(1, 2)).toBe(3)，预期输出是 3，我们需要自己写代码来管理这个 output。

而 snapshot 测试，输出是由 snapshot 文件管理的，咱不需要自己哭哈哈的去改测试文件（当然snapshot有变更的情况下还是要人工看一眼的）。如果确定代码没问题，就用 update 指令更新 snapshot 文件就好了。这样就大大降低了测试的维护成本。

再一个，snapshot 测试用来测试组件外观的时候，比 tobeInTheDocument 这种断言效率更高。只需要一行代码 expect(container).toMatchSnapshot() 就可以了，不需要写一大堆断言来判断组件的各个部分是否存在，是否有正确的文本内容，是否有正确的样式等等。只要 snapshot 文件里保存了组件的外观，那么每次运行测试时就可以直接比较组件的外观和 snapshot 文件里的外观，如果两者不相等，那么测试失败，否则测试通过。

另外，虽然 snapshot 的使用依赖 react render，但 并不意味着 snapshot 只能用在 react 上。其实 snapshot 的核心思想是把输出保存下来，作为一个 snapshot 文件，这个思想是可以应用在任何语言和框架上的。只要我们能把函数的输出保存下来，就可以使用 snapshot 测试。比如很复杂的函数，输出是一个对象，我们可以把这个对象保存下来，作为一个 snapshot 文件。以后每次运行测试时，我们就可以把这个对象和 snapshot 文件进行比较，如果两者不相等，那么测试失败，否则测试通过。

在我个人负责的很多模块里，已经大量使用 snapshot 测试，不仅测试了组件的外观，还测试了函数的输出。感觉 snapshot 测试真的很神，降低了测试的维护成本，提高了测试的效率，让我这个不想写测试的人也能轻松地写测试了。

（完）

附件📎：prompt to Generate unit tests for React components。可以在 vscode copilot chat 里配置使用。

---
description: 'Generate unit tests for React components'
name: 'Generate React Unit Tests'
argument-hint: 'componentPath (required); testFilePath (optional); behavior notes (optional)'
agent: 'agent'
---

Generate Jest + Testing Library unit tests for the React component at componentPath.

Requirements:

- IMPORTANT: import the following testing utilities at the top of the test file:

  ```tsx
  import { render, screen } from '@testing-library/react';
  import React, { ComponentProps } from 'react';
  import 'jest-styled-components';
  ```

- IMPORTANT: Import libraries or dependencies that are directly used by the component.
  - IMPORTANT: Copy the import statements from the source component as it is, don't create new alias like `import { Button as ButtonComponent } `.
  - IMPORTANT: Mock all the libraries or dependencies that are used by the component.
    - Don't mock: `types/**`, `assets/**`, `constants/**`, `styled-components`.
  - IMPORTANT: Mock the ui libraries/dependencies as the below pattern. [IMPORTANT]Use inline([IMPORTANT]) props from ComponentProps to ensure the mock component accepts the same props as the original one:
    ```tsx
    jest.mock('ui-library', () => ({
      //IMPORTANT: Don't create props type manually, use ComponentProps to ensure the mock component accepts the same props as the original one.
      Button: (props: ComponentProps<typeof Button>) => <button {...props} />,
      // mock other components as needed
    }));
    ```
- IMPORTANT: Only generate tests for the component's own logic and rendering. Do not test external libraries, hooks, or context behavior.
- IMPORTANT: Generate snapshot tests for the component's default rendering and for any conditional rendering based on props or state.
- IMPORTANT: Avoiding using toBeInTheDocument/toBeVisible/toHaveTextContent and etc test assertion for appearance verification, prefer snapshot test to verify the rendered output of the component.
- Use `@testing-library/react` with role/label/text-based queries; prefer getByTestId when data-testid exists.
- Use descriptive test names and keep tests DRY via helper functions.
- Avoid hardcoded timeouts and avoid brittle selectors.
- Add JSDoc for any helper functions.
- Prefer web-first assertions (e.g., toBeVisible, toHaveText).
- Do not add comments inside test bodies unless logic is non-obvious.

Inputs:

- componentPath (required): path to the React component file.
- testFilePath (optional): explicit path to the test file.

Test file path:

- If testFilePath is provided, use it.
- Otherwise, derive it as: same folder as componentPath, with "{{componentFileName without ext}}.test.tsx".

Output:

- Provide the full test file content.
- Mention the intended test file path if it is not obvious from context.

Assumptions:

- If the component file extension is .ts or .tsx, generate .test.tsx.
- If the component is not export-default, include a named import in the test.

Example invocations:

- /Generate React Unit Tests componentPath=src/components/Button.tsx
- /Generate React Unit Tests componentPath=src/components/Button.tsx testFilePath=src/components/**tests**/Button.test.tsx