diff --git a/blog/vitest-3-2.md b/blog/vitest-3-2.md index f6307e01..7c8130c1 100644 --- a/blog/vitest-3-2.md +++ b/blog/vitest-3-2.md @@ -1,7 +1,7 @@ --- -title: Vitest 3.2 is out! +title: Vitest 3.2 发布了! author: - name: The Vitest Team + name: Vitest 团队 date: 2025-06-02 sidebar: false head: @@ -10,48 +10,48 @@ head: content: website - - meta - property: og:title - content: Announcing Vitest 3.2 + content: Vitest 3.2 发布了 - - meta - property: og:image - content: https://vitest.dev/og-vitest-3-2.png + content: https://cn.vitest.dev/og-vitest-3-2.png - - meta - property: og:url - content: https://vitest.dev/blog/vitest-3-2 + content: https://cn.vitest.dev/blog/vitest-3-2 - - meta - property: og:description - content: Vitest 3.2 Release Announcement + content: Vitest 3.2 发布公告 - - meta - name: twitter:card content: summary_large_image --- -# Vitest 3.2 is out! +# Vitest 3.2 发布了! -_June 2, 2025_ +_2025 年 6 月 2 日_ -![Vitest 3.2 Announcement Cover Image](/og-vitest-3-2.png) +![Vitest 3.2 公告封面图](/og-vitest-3-2.png) -Vitest 3.2 focuses on improvements to Browser Mode and TypeScript support. This release also includes some new useful methods, config options and deprecates the `workspace` config in favour of `projects`. +Vitest 3.2 专注于改进浏览器模式和 TypeScript 支持。此版本还包含一些新的实用方法、配置选项,并弃用了 `workspace` 配置,转而推荐使用 `projects`。 -## `workspace` is Deprecated +## `workspace` 已弃用 {#workspace-is-deprecated} -In an effort to simplify the configuration, the team decided to deprecate the separate `vitest.workspace` file and recommend using only the `projects` option in the root config. This also simplifies how the global options are configured (because you don't need to guess how to add reporters when you have no root config). +为了简化配置,团队决定弃用单独的 `vitest.workspace` 文件,推荐仅在根配置中使用 `projects` 选项。这也简化了全局选项的配置方式(因为当你没有根配置时,不需要再猜测如何添加报告器)。 -We also decided to deprecate the `workspace` name because it clashes with other tools like PNPM that provide monorepo support via this option. Vitest doesn't run these projects with separate `CWD` and treats them more like sub-Vitests. It also gives us more space to come up with a better solution for monorepos without breaking others. +我们还决定弃用 `workspace` 这个名称,因为它与 PNPM 等工具通过该选项提供 monorepo 支持功能存在冲突。Vitest 不会为这些项目分配独立的 `工作目录(CWD)`,而是将其视为子 Vitest 实例。这也为我们提供了更多空间,以便在不破坏其他功能的情况下为 monorepo 提供更好的解决方案。 -This option will be removed completely in a future major, replaced by `projects`. Until then, Vitest will print a warning if workspace feature is used. +此选项将在未来的主版本中完全移除,由 `projects` 取代。在此之前,如果使用了 workspace 功能,Vitest 将打印警告。 -## Annotation API +## 注释 API {#annotation-api} -The new [annotation API](/guide/test-annotations) allows you to annotate any test with a custom message and attachment. These annotations are visible in the UI, HTML, junit, tap and GitHub Actions reporters. Vitest will also print related annotation in the CLI if the test fails. +新的 [注释 API](/guide/test-annotations) 允许你为任何测试添加自定义消息和附件。这些注释在 UI、HTML、junit、tap 和 GitHub Actions 报告器中可见。如果测试失败,Vitest 还会在 CLI 中打印相关注释。 -## Scoped Fixtures +## 作用域固定装置 {#scoped-fixtures} -The `test.extend` fixtures can now specify the `scope` option: either `file` or `worker`. +`test.extend` 固定装置现在可以指定 `scope` 选项:`file` 或 `worker`。 ```ts const test = baseTest.extend({ @@ -66,15 +66,15 @@ const test = baseTest.extend({ }) ``` -The file fixture is similar to using `beforeAll` and `afterAll` at the top level of the file, but it won't be called if the fixture is not used in any test. +`file` 固定装置类似于在文件顶层使用 `beforeAll` 和 `afterAll`,但如果没有任何测试使用该固定装置,它就不会被调用。 -The `worker` fixture is initiated once per worker, but note that by default Vitest creates one worker for every test, so you need to disable [isolation](/config/#isolate) to benefit from it. +`worker` 固定装置在每个工作线程中仅初始化一次。但请注意,默认情况下 Vitest 为每个测试创建独立工作线程,因此需要禁用 [隔离模式](/config/#isolate) 才能生效。 -## Custom Project Name Colors +## 自定义项目名称颜色 {#custom-project-name-colors} -You can now set a custom [color](/config/#name) when using `projects`: +使用 `projects` 时,你现在可以设置自定义 [颜色](/config/#name): -::: details Config Example +::: details 配置示例 ```ts{6-9,14-17} export default defineConfig({ test: { @@ -108,9 +108,9 @@ export default defineConfig({ -## Custom Browser Locators API +## 自定义浏览器定位器 API {#custom-browser-locators-api} -Built-in locators might not be enough to express your application’s needs. Instead of falling back to CSS and losing the retry-ability protection that Vitest provides through its locator API, we now recommend extending locators using the new [`locators.extend` API](/guide/browser/locators#custom-locators). +当内置定位器无法满足应用需求时。与其降级使用 CSS 选择器,并牺牲 Vitest 定位器 API 提供的重试保护机制,不如推荐你使用 [`locators.extend` API](/guide/browser/locators#custom-locators) 扩展定位器。 ```ts import { locators } from '@vitest/browser/context' @@ -122,9 +122,9 @@ locators.extend({ }) ``` -Return a Playwright [locator string](https://playwright.dev/docs/other-locators) to construct a new locator. Note that string returned from this method will be scoped to the parent locator, if there is one. +返回 Playwright [定位器字符串](https://playwright.dev/docs/other-locators)来构造新的定位器。请注意,从此方法返回的字符串将用作于父定位器范围内(如果有的话)。 -Now you can call `getByCommentsCount` on the `page` or any other locator directly: +现在你可以直接在 `page` 对象或任何其他定位器上调用 `getByCommentsCount`: ```ts await expect.element(page.getByCommentsCount(1)).toBeVisible() @@ -134,7 +134,7 @@ await expect.element( ).toBeVisible() ``` -If this method returns a string, then the return value will be converted into a locator, so you can keep chaining it: +如果此方法返回字符串,返回值将被转换为定位器对象,因此你可以继续链式调用: ```ts page.getByRole('article', { name: 'Hello World' }) @@ -142,7 +142,7 @@ page.getByRole('article', { name: 'Hello World' }) .getByText('comments') ``` -This method has access to the current locator context, if there is one (if method is called on the `page`, then context will refer to `page`), so you can chain all locator methods inside: +此方法可以访问当前的定位器上下文(如果有的话,在 `page` 对象上调用时,则上下文指向 `page`),因此你可以在内部链式调用所有定位器方法: ```ts import type { Locator } from '@vitest/browser/context' @@ -156,7 +156,7 @@ locators.extend({ }) ``` -Having access to context also allows you to call regular methods of the locator to define a custom user event: +通过访问上下文,你还可以调用定位器的常规方法来定义自定义用户事件: ```ts import type { Locator } from '@vitest/browser/context' @@ -172,11 +172,11 @@ locators.extend({ await page.getByRole('textbox').clickAndFill('Hello World') ``` -Please, refer to the [`locators.extend` API](/guide/browser/locators#custom-locators) for more information. +请参阅 [`locators.extend` API](/guide/browser/locators#custom-locators) 获取更多信息。 -## Explicit Resource Management in `vi.spyOn` and `vi.fn` +## `vi.spyOn` 和 `vi.fn` 中的显式资源管理 {#explicit-resource-management-in-vi-spyon-and-vi-fn} -In environments that support [Explicit Resource Management](https://github.com/tc39/proposal-explicit-resource-management), you can use `using` instead of `const` to automatically call `mockRestore` on any mocked function when the containing block is exited. This is especially useful for spied methods: +在支持 [显式资源管理](https://github.com/tc39/proposal-explicit-resource-management) 的环境中,你可以使用 `using` 代替 `const`,以便在包含块退出时自动对任何模拟函数调用 `mockRestore`。这对于监听方法特别有用: ```ts it('calls console.log', () => { @@ -185,16 +185,16 @@ it('calls console.log', () => { expect(spy).toHaveBeenCalled() }) -// console.log is restored here +// console.log 在此处还原 ``` -## Test `signal` API +## 测试 `signal` API {#test-signal-api} -Vitest now provides an [`AbortSignal`](https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal) object to the test body. You can use it to stop any resource that supports this Web API. +Vitest 现在向测试主体提供一个 [`AbortSignal`](https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal) 对象。你可以使用它来停止任何支持此 Web API 的资源。 -The signal is aborted when test times out, another test fails and [`--bail` flag](/config/#bail) is set to a non-zero value, or the user presses Ctrl+C in the terminal. +当测试超时、其他测试失败且 [`--bail` 标志](/config/#bail) 设置为非零值,或者用户在终端中按下 Ctrl+C 时,信号会被中止。 -For example, you can stop a `fetch` request when tests are interrupted: +例如,你可以在测试中断时停止 `fetch` 请求: ```ts it('stop request when test times out', async ({ signal }) => { @@ -202,17 +202,17 @@ it('stop request when test times out', async ({ signal }) => { }, 2000) ``` -## Coverage V8 AST-aware remapping +## Coverage V8 AST 感知重映射 {#coverage-v8-ast-aware-remapping} -Vitest now uses `ast-v8-to-istanbul` package developed by one of the Vitest maintainers, [AriPerkkio](https://github.com/AriPerkkio). This brings v8 coverage report in line with istanbul, but has a better performance! Enable this feature by setting [`coverage.experimentalAstAwareRemapping`](/config/#coverage-experimentalastawareremapping) to `true`. +Vitest 现在使用由 Vitest 维护者之一 [AriPerkkio](https://github.com/AriPerkkio) 开发的 `ast-v8-to-istanbul` 包。这使 v8 覆盖率报告与 istanbul 保持一致,但性能更好!通过将 [`coverage.experimentalAstAwareRemapping`](/config/#coverage-experimentalastawareremapping) 设置为 `true` 来启用此功能。 -We are planning to make this the default remapping mode in the next major. The old `v8-to-istanbul` will be removed completely. Feel free to join discussion at https://github.com/vitest-dev/vitest/issues/7928. +我们计划在下一个主版本中将此作为默认重映射模式。旧的 `v8-to-istanbul` 将被完全移除。欢迎在 https://github.com/vitest-dev/vitest/issues/7928 参与讨论。 -## `watchTriggerPatterns` Option +## `watchTriggerPatterns` 选项 {#watchtriggerpatterns-option} -When you edit a file, Vitest is smart enough to rerun only tests that import this file. Unfortunately, Vitest static analysis respects only static and dynamic `import` statement. If you are reading a file or starting a separate process, Vitest will ignore changes to related files. +当你编辑文件时,Vitest 会智能地仅重新运行导入该文件的测试。遗憾的是,Vitest 的静态分析只支持静态和动态 `import` 语句。如果你通过文件读取或启动单独的进程,Vitest 将忽略相关文件的更改。 -With `watchTriggerPatterns` option you can configure which tests to rerun depending on the file that was changed. For example, to always rerun `mailers` tests when a template is changed, add a trigger pattern: +使用 `watchTriggerPatterns` 选项,你可以配置根据更改的文件重新运行哪些测试。例如,如果想要在更改模板时始终重新运行 `mailers` 测试,可以添加一个触发模式: ```ts export default defineConfig({ @@ -229,15 +229,15 @@ export default defineConfig({ }) ``` -## The New Multi-Purpose `Matchers` Type +## 新的多用途 `Matchers` 类型 {#the-new-multi-purpose-matchers-type} -Vitest now has a `Matchers` type that you can extend to add type support for all your custom matchers in one place. This type affects all these use cases: +Vitest 现在有一个 `Matchers` 类型,你可以扩展它来在一个地方为所有自定义匹配器添加类型支持。此类型影响以下所有用例: - `expect().to*` - `expect.to*` - `expect.extend({ to* })` -For example, to have a type-safe `toBeFoo` matcher, you can write something like this: +例如,要拥有一个类型安全的 `toBeFoo` 匹配器,你可以这样写: ```ts twoslash import { expect } from 'vitest' @@ -253,7 +253,7 @@ declare module 'vitest' { expect.extend({ toBeFoo(actual, arg) { // ^? - // ... implementation + // 具体实现... return { pass: true, message: () => '', @@ -267,14 +267,14 @@ expect.toBeFoo('foo') ## `sequence.groupOrder` -The new [`sequence.groupOrder`](/config/#grouporder) option controls the order in which the project runs its tests when using multiple [projects](/guide/projects). +新的 [`sequence.groupOrder`](/config/#grouporder) 选项控制在使用多个 [projects](/guide/projects) 时项目测试执行的顺序。 -- Projects with the same group order number will run together, and groups are run from lowest to highest. -- If you don’t set this option, all projects run in parallel. -- If several projects use the same group order, they will run at the same time. +- 具有相同分组序号的测试项目将并行运行,各组按序号从低到高依次执行。 +- 若未设置此选项,所有项目将默认并行执行。 +- 当多个项目使用相同分组序号时,它们将同时执行。 -::: details Example -Consider this example: +::: details 示例 +考虑这个例子: ```ts import { defineConfig } from 'vitest/config' @@ -311,17 +311,17 @@ export default defineConfig({ }) ``` -Tests in these projects will run in this order: +这些项目中的测试将按以下顺序运行: ``` 0. slow | - |> running together + |> 并行执行 0. fast | - 1. flaky |> runs after slow and fast alone + 1. flaky |> 在 slow 和 fast 之后单独运行 ``` ::: ---- -The complete list of changes is at the [Vitest 3.2 Changelog](https://github.com/vitest-dev/vitest/releases/tag/v3.2.0). +完整的更改列表请查看 [Vitest 3.2 更新日志](https://github.com/vitest-dev/vitest/releases/tag/v3.2.0)。 diff --git a/blog/vitest-3.md b/blog/vitest-3.md index 317769ee..e681a64e 100644 --- a/blog/vitest-3.md +++ b/blog/vitest-3.md @@ -1,7 +1,7 @@ --- title: Vitest 3.0 发布了! author: - name: The Vitest Team + name: Vitest 团队 date: 2025-01-17 sidebar: false head: @@ -13,13 +13,13 @@ head: content: Vitest 3.0 发布了! - - meta - property: og:image - content: https://vitest.dev/og-vitest-3.jpg + content: https://cn.vitest.dev/og-vitest-3.jpg - - meta - property: og:url - content: https://vitest.dev/blog/vitest-3 + content: https://cn.vitest.dev/blog/vitest-3 - - meta - property: og:description - content: Vitest 3.0 Release Announcement + content: Vitest 3.0 发布公告 - - meta - name: twitter:card content: summary_large_image @@ -27,9 +27,9 @@ head: # Vitest 3.0 发布了! -_January 17, 2025_ +_2025 年 1 月 17 日_ -![Vitest 3 Announcement Cover Image](/og-vitest-3.jpg) +![Vitest 3 公告封面图](/og-vitest-3.jpg) 我们在半年前发布了 Vitest 2。我们见证了它被广泛采用,每周 npm 下载量从 480 万次增长到 770 万次。我们的生态系统也在快速发展。其中包括,Storybook 新的测试功能由我们的 VS Code 扩展和浏览器模式提供支持,以及 Matt Pocock 正在基于 Vitest 开发 Evalite,这是一个用于评估 AI 驱动应用的工具。 diff --git a/guide/browser/examples.md b/guide/browser/examples.md deleted file mode 100644 index 3695b003..00000000 --- a/guide/browser/examples.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -title: Examples | Browser Mode ---- - -# Examples - -浏览器模式与框架无关,因此不提供任何渲染组件的方法。不过,你应该可以使用框架的测试工具包。 - -我们建议根据您的框架使用 `testing-library` packages: - -- [`@testing-library/dom`](https://testing-library.com/docs/dom-testing-library/intro) if you don't use a framework -- [`@testing-library/vue`](https://testing-library.com/docs/vue-testing-library/intro) to render [vue](https://vuejs.org) components -- [`@testing-library/svelte`](https://testing-library.com/docs/svelte-testing-library/intro) to render [svelte](https://svelte.dev) components -- [`@testing-library/react`](https://testing-library.com/docs/react-testing-library/intro) to render [react](https://react.dev) components -- [`@testing-library/preact`](https://testing-library.com/docs/preact-testing-library/intro) to render [preact](https://preactjs.com) components -- [`@solidjs/testing-library`](https://testing-library.com/docs/solid-testing-library/intro) to render [solid](https://www.solidjs.com) components -- [`@marko/testing-library`](https://testing-library.com/docs/marko-testing-library/intro) to render [marko](https://markojs.com) components - -::: warning -`testing-library` 提供了一个包`@testing-library/user-event`。我们不建议直接使用它,因为它会模拟事件而非实际触发事件--相反,请使用从 `@vitest/browser/context`导入的 [`userEvent`](#interactivity-api),它使用 Chrome DevTools 协议或 Webdriver(取决于provider)。 -::: - -::: code-group -```ts [vue] -// based on @testing-library/vue example -// https://testing-library.com/docs/vue-testing-library/examples - -import { render, screen } from '@testing-library/vue' -import { userEvent } from '@vitest/browser/context' -import Component from './Component.vue' - -test('properly handles v-model', async () => { - render(Component) - - // Asserts initial state. - expect(screen.getByText('Hi, my name is Alice')).toBeInTheDocument() - - // Get the input DOM node by querying the associated label. - const usernameInput = await screen.findByLabelText(/username/i) - - // Type the name into the input. This already validates that the input - // is filled correctly, no need to check the value manually. - await userEvent.fill(usernameInput, 'Bob') - - expect(screen.getByText('Hi, my name is Alice')).toBeInTheDocument() -}) -``` -```ts [svelte] -// based on @testing-library/svelte -// https://testing-library.com/docs/svelte-testing-library/example - -import { render, screen } from '@testing-library/svelte' -import { userEvent } from '@vitest/browser/context' -import { expect, test } from 'vitest' - -import Greeter from './greeter.svelte' - -test('greeting appears on click', async () => { - const user = userEvent.setup() - render(Greeter, { name: 'World' }) - - const button = screen.getByRole('button') - await user.click(button) - const greeting = await screen.findByText(/hello world/iu) - - expect(greeting).toBeInTheDocument() -}) -``` -```tsx [react] -// based on @testing-library/react example -// https://testing-library.com/docs/react-testing-library/example-intro - -import { render, screen } from '@testing-library/react' -import { userEvent } from '@vitest/browser/context' -import Fetch from './fetch' - -test('loads and displays greeting', async () => { - // Render a React element into the DOM - render() - - await userEvent.click(screen.getByText('Load Greeting')) - // wait before throwing an error if it cannot find an element - const heading = await screen.findByRole('heading') - - // assert that the alert message is correct - expect(heading).toHaveTextContent('hello there') - expect(screen.getByRole('button')).toBeDisabled() -}) -``` -```tsx [preact] -// based on @testing-library/preact example -// https://testing-library.com/docs/preact-testing-library/example - -import { render } from '@testing-library/preact' -import { userEvent } from '@vitest/browser/context' -import { h } from 'preact' - -import HiddenMessage from '../hidden-message' - -test('shows the children when the checkbox is checked', async () => { - const testMessage = 'Test Message' - - const { queryByText, getByLabelText, getByText } = render( - {testMessage}, - ) - - // query* functions will return the element or null if it cannot be found. - // get* functions will return the element or throw an error if it cannot be found. - expect(queryByText(testMessage)).not.toBeInTheDocument() - - // The queries can accept a regex to make your selectors more - // resilient to content tweaks and changes. - await userEvent.click(getByLabelText(/show/i)) - - expect(getByText(testMessage)).toBeInTheDocument() -}) -``` -```tsx [solid] -// baed on @testing-library/solid API -// https://testing-library.com/docs/solid-testing-library/api - -import { render } from '@testing-library/solid' - -it('uses params', async () => { - const App = () => ( - <> - ( -

- Id: - {useParams()?.id} -

- )} - /> -

Start

} /> - - ) - const { findByText } = render(() => , { location: 'ids/1234' }) - expect(await findByText('Id: 1234')).toBeInTheDocument() -}) -``` -```ts [marko] -// baed on @testing-library/marko API -// https://testing-library.com/docs/marko-testing-library/api - -import { render, screen } from '@marko/testing-library' -import Greeting from './greeting.marko' - -test('renders a message', async () => { - const { container } = await render(Greeting, { name: 'Marko' }) - expect(screen.getByText(/Marko/)).toBeInTheDocument() - expect(container.firstChild).toMatchInlineSnapshot(` -

Hello, Marko!

- `) -}) -``` -::: diff --git a/guide/browser/trace-view.md b/guide/browser/trace-view.md index d78db55d..d20cf84e 100644 --- a/guide/browser/trace-view.md +++ b/guide/browser/trace-view.md @@ -1,9 +1,9 @@ -# Trace View +# 追踪视图 {#trace-view} -Vitest Browser Mode supports generating Playwright's [trace files](https://playwright.dev/docs/trace-viewer#viewing-remote-traces). To enable tracing, you need to set the [`trace`](/guide/browser/config#browser-trace) option in the `test.browser` configuration. +Vitest 浏览器模式支持生成 Playwright 的 [追踪文件](https://playwright.dev/docs/trace-viewer#viewing-remote-traces)。要启用追踪功能,需要在 `test.browser` 配置中设置 [`trace`](/guide/browser/config#browser-trace) 选项。 ::: warning -Generating trace files is only available when using the [Playwright provider](/guide/browser/playwright). +生成追踪文件仅在使用 [Playwright provider](/guide/browser/playwright) 时可用。 ::: ::: code-group @@ -25,17 +25,17 @@ vitest --browser.trace=on ``` ::: -By default, Vitest will generate a trace file for each test. You can also configure it to only generate traces on test failures by setting `trace` to `'on-first-retry'`, `'on-all-retries'` or `'retain-on-failure'`. The files will be saved in `__traces__` folder next to your test files. The name of the trace includes the project name, the test name, the [`repeats` count and `retry` count](/api/#test-api-reference): +默认情况下,Vitest 会为每个测试生成一个追踪文件。你也可以通过设置 `trace` 为 `'on-first-retry'`、`'on-all-retries'` 或 `'retain-on-failure'` 来配置仅在测试失败时生成追踪。这些文件将保存在测试文件相邻的 `__traces__` 文件夹中。追踪文件的名称包括项目名称、测试名称、[`repeats` 次数和 `retry` 次数](/api/#test-api-reference): ``` chromium-my-test-0-0.trace.zip -^^^^^^^^ project name - ^^^^^^ test name - ^ repeat count - ^ retry count +^^^^^^^^ 项目名称 + ^^^^^^ 测试名称 + ^ 重复次数 + ^ 重试次数 ``` -To change the output directory, you can set the `tracesDir` option in the `test.browser.trace` configuration. This way all traces will be stored in the same directory, grouped by the test file. +要更改输出目录,可以在 `test.browser.trace` 配置中设置 `tracesDir` 选项。这样所有追踪文件将按测试文件分组存储在同一目录中。 ```ts [vitest.config.js] import { defineConfig } from 'vitest/config' @@ -47,7 +47,7 @@ export default defineConfig({ provider: playwright(), trace: { mode: 'on', - // the path is relative to the root of the project + // 路径相对于项目根目录 tracesDir: './playwright-traces', }, }, @@ -55,20 +55,20 @@ export default defineConfig({ }) ``` -The traces are available in reporters as [annotations](/guide/test-annotations). For example, in the HTML reporter, you can find the link to the trace file in the test details. +追踪文件在报告器中作为 [注释](/guide/test-annotations) 形式呈现。例如,在 HTML 报告器中,你可以在测试详情页中找到追踪文件的链接。 -## Preview +## 预览 {#preview} -To open the trace file, you can use the Playwright Trace Viewer. Run the following command in your terminal: +要打开追踪文件,可以使用 Playwright Trace Viewer。在终端中运行以下命令: ```bash npx playwright show-trace "path-to-trace-file" ``` -This will start the Trace Viewer and load the specified trace file. +这将启动 Trace Viewer 并加载指定的追踪文件。 -Alternatively, you can open the Trace Viewer in your browser at https://trace.playwright.dev and upload the trace file there. +或者,你可以在浏览器中打开 https://trace.playwright.dev 并在那里上传追踪文件。 -## Limitations +## 限制 {#limitations} -At the moment, Vitest cannot populate the "Sources" tab in the Trace Viewer. This means that while you can see the actions and screenshots captured during the test, you won't be able to view the source code of your tests directly within the Trace Viewer. You will need to refer back to your code editor to see the test implementation. +目前,Vitest 无法填充 Trace Viewer 中的 "Sources" 标签页。这意味着虽然你可以看到测试期间捕获的操作和截图,但无法直接在 Trace Viewer 中查看测试的源代码。你需要返回代码编辑器查看测试实现。 diff --git a/guide/examples/projects-workspace.md b/guide/examples/projects-workspace.md index e57ad84c..42c2634b 100644 --- a/guide/examples/projects-workspace.md +++ b/guide/examples/projects-workspace.md @@ -2,7 +2,7 @@ import { defineConfig } from "vitest/config"; export default defineConfig({ test: { - // "test.workspace" is now "test.projects" + // "test.workspace" 现已更名为 "test.projects" workspace: [ // [!code --] projects: [ // [!code ++] { test: { name: "Unit" } }, diff --git a/guide/test-annotations.md b/guide/test-annotations.md index 88f23625..f20e1e91 100644 --- a/guide/test-annotations.md +++ b/guide/test-annotations.md @@ -3,9 +3,9 @@ title: Test Annotations | Guide outline: deep --- -# Test Annotations +# 测试注释 {#test-annotations} -Vitest supports annotating your tests with custom messages and files via the [`context.annotate`](/guide/test-context#annotate) API. These annotations will be attached to the test case and passed down to reporters in the [`onTestAnnotate`](/advanced/api/reporters#ontestannotate) hook. +Vitest 支持通过 [`context.annotate`](/guide/test-context#annotate) API 为测试添加自定义消息和文件注释。这些注释会附加到测试用例上,并通过 [`onTestAnnotate`](/advanced/api/reporters#ontestannotate) 钩子传递给报告器。 ```ts test('hello world', async ({ annotate }) => { @@ -21,15 +21,15 @@ test('hello world', async ({ annotate }) => { ``` ::: warning -The `annotate` function returns a Promise, so it needs to be awaited if you rely on it somehow. However, Vitest will also automatically await any non-awaited annotation before the test finishes. +`annotate` 函数返回一个 Promise,因此如果你依赖它的结果需使用 await。不过,Vitest 也会在测试结束前自动等待任何未被 await 的注释完成。 ::: -Depending on your reporter, you will see these annotations differently. +根据你使用的报告器不同,注释的显示方式也会有所差异。 -## Built-in Reporters +## 内置报告器 {#built-in-reporters} ### default -The `default` reporter prints annotations only if the test has failed: +`default` 报告器仅在测试失败时打印注释: ``` ⎯⎯⎯⎯⎯⎯⎯ Failed Tests 1 ⎯⎯⎯⎯⎯⎯⎯ @@ -53,7 +53,7 @@ Error: thrown error ### verbose -The `verbose` reporter is the only terminal reporter that reports annotations when the test doesn't fail. +`verbose` 报告器是唯一一个在测试通过时也会报告注释的终端报告器。 ``` ✓ example.test.js > an example of a test with annotation @@ -67,14 +67,14 @@ The `verbose` reporter is the only terminal reporter that reports annotations wh ### html -The HTML reporter shows annotations the same way the UI does. You can see the annotation on the line where it was called. At the moment, if the annotation wasn't called in a test file, you cannot see it in the UI. We are planning to support a separate test summary view where it will be visible. +HTML 报告器以与 UI 模式相同的方式显示注释。你可以在调用注释的那一行看到它。目前,如果注释不是在测试文件中调用的,你将无法在界面中看到它。我们计划支持单独的测试摘要视图来展示这些注释。 Vitest UI Vitest UI ### junit -The `junit` reporter lists annotations inside the testcase's `properties` tag. The JUnit reporter will ignore all attachments and will print only the type and the message. +`junit` 报告器将注释列在测试用例的 `properties` 标签内。JUnit 报告器会忽略所有附件,仅打印注释类型和消息内容。 ```xml @@ -87,14 +87,14 @@ The `junit` reporter lists annotations inside the testcase's `properties` tag. T ### github-actions -The `github-actions` reporter will print the annotation as a [notice message](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#setting-a-notice-message) by default. You can configure the `type` by passing down the second argument as `notice`, `warning` or `error`. If type is none of these, Vitest will show the message as a notice. +`github-actions` 报告器默认将注释打印为 [notice 消息](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#setting-a-notice-message)。你可以通过传递第二个参数来配置 `type`,可选值为 `notice`、`warning` 或 `error`。如果类型不是这些值之一,Vitest 将以 notice 形式显示消息。 GitHub Actions GitHub Actions ### tap -The `tap` and `tap-flat` reporters print annotations as diagnostic messages on a new line starting with a `#` symbol. They will ignore all attachments and will print only the type and message: +`tap` 和 `tap-flat` 报告器将注释打印为新行上以 `#` 符号开头的诊断消息。它们会忽略所有附件,只打印类型和消息: ``` ok 1 - an example of a test with annotation # time=143.15ms