@vitest-agent/mcp 1.1.0 → 1.2.0

package/vendor/vitest-docs/guide/index.md

@@ -1,128 +0,0 @@
-# Getting Started
-
-## Overview
-
-Vitest (pronounced as _"veetest"_) is a next generation testing framework
-powered by
-Vite.
-
-You can learn more about the rationale behind the project in the [Why Vitest](/guide/why) section.
-
-## Trying Vitest Online
-
-You can try Vitest online on [StackBlitz](https://vitest.new). It runs Vitest directly in the browser, and it is almost identical to the local setup but doesn't require installing anything on your machine.
-
-## Adding Vitest to Your Project
-
-<CourseLink href="https://vueschool.io/lessons/how-to-install-vitest?friend=vueuse">Learn how to install by Video</CourseLink>
-
-::: code-group
-```bash [npm]
-npm install -D vitest
-```
-```bash [yarn]
-yarn add -D vitest
-```
-```bash [pnpm]
-pnpm add -D vitest
-```
-```bash [bun]
-bun add -D vitest
-```
-:::
-
-:::tip
-Vitest requires Vite >=v6.0.0 and Node >=v20.0.0
-:::
-
-It is recommended that you install a copy of `vitest` in your `package.json`, using one of the methods listed above. However, if you would prefer to run `vitest` directly, you can use `npx vitest` (the `npx` tool comes with npm and Node.js).
-
-The `npx` tool will execute the specified command. By default, `npx` will first check if the command exists in the local project's binaries. If it is not found there, `npx` will look in the system's `$PATH` and execute it if found. If the command is not found in either location, `npx` will install it in a temporary location prior to execution.
-
-## Writing Tests
-
-As an example, we will write a simple test that verifies the output of a function that adds two numbers.
-
-``` js [sum.js]
-export function sum(a, b) {
-  return a + b
-}
-```
-
-``` js [sum.test.js]
-import { expect, test } from 'vitest'
-import { sum } from './sum.js'
-
-test('adds 1 + 2 to equal 3', () => {
-  expect(sum(1, 2)).toBe(3)
-})
-```
-
-::: tip
-By default, tests must contain `.test.` or `.spec.` in their file name.
-:::
-
-Next, in order to execute the test, add the following section to your `package.json`:
-
-```json [package.json]
-{
-  "scripts": {
-    "test": "vitest"
-  }
-}
-```
-
-Finally, run `npm run test`, `yarn test` or `pnpm test`, depending on your package manager, and Vitest will print this message:
-
-```txt
-✓ sum.test.js (1)
-  ✓ adds 1 + 2 to equal 3
-
-Test Files  1 passed (1)
-     Tests  1 passed (1)
-  Start at  02:15:44
-  Duration  311ms
-```
-
-::: warning
-If you are using Bun as your package manager, make sure to use `bun run test` command instead of `bun test`, otherwise Bun will run its own test runner.
-:::
-
-Your first test is passing! Continue to [Writing Tests](/guide/learn/writing-tests) to learn about organizing tests, reading test output, and the core testing patterns you'll use every day.
-
-To run tests once without watching for file changes, use `vitest run`. You can also pass additional flags like `--reporter` or `--coverage`. For a full list of CLI options, run `npx vitest --help` or see the [CLI guide](/guide/cli).
-
-## Configuring Vitest
-
-Vitest reads your `vite.config.*` by default, so your existing Vite plugins and configuration work out-of-the-box. You can also create a dedicated `vitest.config.*` for test-specific settings. See the [Config Reference](/config/) for details.
-
-## IDE Integrations
-
-We also provided an official extension for Visual Studio Code to enhance your testing experience with Vitest.
-
-[Install from VS Code Marketplace](https://marketplace.visualstudio.com/items?itemName=vitest.explorer)
-
-Learn more about [IDE Integrations](/guide/ide)
-
-## Examples
-
-| Example | Source | Playground |
-|---|---|---|
-| `basic` | [GitHub](https://github.com/vitest-dev/vitest/tree/main/examples/basic) | [Play Online](https://stackblitz.com/fork/github/vitest-dev/vitest/tree/main/examples/basic?initialPath=__vitest__/) |
-| `fastify` | [GitHub](https://github.com/vitest-dev/vitest/tree/main/examples/fastify) | [Play Online](https://stackblitz.com/fork/github/vitest-dev/vitest/tree/main/examples/fastify?initialPath=__vitest__/) |
-| `in-source-test` | [GitHub](https://github.com/vitest-dev/vitest/tree/main/examples/in-source-test) | [Play Online](https://stackblitz.com/fork/github/vitest-dev/vitest/tree/main/examples/in-source-test?initialPath=__vitest__/) |
-| `lit` | [GitHub](https://github.com/vitest-dev/vitest/tree/main/examples/lit) | [Play Online](https://stackblitz.com/fork/github/vitest-dev/vitest/tree/main/examples/lit?initialPath=__vitest__/) |
-| `vue` | [GitHub](https://github.com/vitest-tests/browser-examples/tree/main/examples/vue) | [Play Online](https://stackblitz.com/fork/github/vitest-tests/browser-examples/tree/main/examples/vue?initialPath=__vitest__/) |
-| `marko` | [GitHub](https://github.com/vitest-tests/browser-examples/tree/main/examples/marko) | [Play Online](https://stackblitz.com/fork/github/vitest-tests/browser-examples/tree/main/examples/marko?initialPath=__vitest__/) |
-| `preact` | [GitHub](https://github.com/vitest-tests/browser-examples/tree/main/examples/preact) | [Play Online](https://stackblitz.com/fork/github/vitest-tests/browser-examples/tree/main/examples/preact?initialPath=__vitest__/) |
-| `qwik` | [GitHub](https://github.com/vitest-tests/browser-examples/tree/main/examples/qwik) | [Play Online](https://stackblitz.com/fork/github/vitest-tests/browser-examples/tree/main/examples/qwik?initialPath=__vitest__/) |
-| `react` | [GitHub](https://github.com/vitest-tests/browser-examples/tree/main/examples/react) | [Play Online](https://stackblitz.com/fork/github/vitest-tests/browser-examples/tree/main/examples/react?initialPath=__vitest__/) |
-| `solid` | [GitHub](https://github.com/vitest-tests/browser-examples/tree/main/examples/solid) | [Play Online](https://stackblitz.com/fork/github/vitest-tests/browser-examples/tree/main/examples/solid?initialPath=__vitest__/) |
-| `svelte` | [GitHub](https://github.com/vitest-tests/browser-examples/tree/main/examples/svelte) | [Play Online](https://stackblitz.com/fork/github/vitest-tests/browser-examples/tree/main/examples/svelte?initialPath=__vitest__/) |
-| `profiling` | [GitHub](https://github.com/vitest-dev/vitest/tree/main/examples/profiling) | Not Available |
-| `typecheck` | [GitHub](https://github.com/vitest-dev/vitest/tree/main/examples/typecheck) | [Play Online](https://stackblitz.com/fork/github/vitest-dev/vitest/tree/main/examples/typecheck?initialPath=__vitest__/) |
-| `projects` | [GitHub](https://github.com/vitest-dev/vitest/tree/main/examples/projects) | [Play Online](https://stackblitz.com/fork/github/vitest-dev/vitest/tree/main/examples/projects?initialPath=__vitest__/) |
-
-## Community
-
-If you have questions or need help, reach out to the community at [Discord](https://chat.vitest.dev) and [GitHub Discussions](https://github.com/vitest-dev/vitest/discussions).

package/vendor/vitest-docs/guide/learn/async.md

@@ -1,147 +0,0 @@
-# Testing Asynchronous Code
-
-JavaScript code frequently runs asynchronously. Whether you're fetching data, reading files, or waiting on timers, Vitest needs to know when the code it is testing has completed before moving on to the next test. Here are the patterns you'll use most often.
-
-## Async/Await
-
-The most straightforward approach is to make your test function `async`. Vitest will automatically wait for the returned promise to resolve before considering the test complete. If the promise rejects, the test fails with the rejection reason.
-
-```js
-import { expect, test } from 'vitest'
-
-function fetchUser(id) {
-  return Promise.resolve({ id, name: 'Alice' })
-}
-
-test('fetches user by id', async () => {
-  const user = await fetchUser(1)
-  expect(user.name).toBe('Alice')
-})
-```
-
-This is the pattern you'll use the vast majority of the time. It reads just like synchronous code, and errors propagate naturally through `await`.
-
-## Resolves and Rejects
-
-Sometimes you'd rather assert on a promise directly instead of `await`-ing it into a variable first. The [`.resolves`](/api/expect#resolves) and [`.rejects`](/api/expect#rejects) helpers let you do this. They unwrap the promise and then apply the matcher to the resolved or rejected value:
-
-```js
-test('resolves to Alice', async () => {
-  await expect(fetchUser(1)).resolves.toMatchObject({ name: 'Alice' })
-})
-
-test('rejects with an error', async () => {
-  await expect(fetchInvalidUser()).rejects.toThrow('User not found')
-})
-```
-
-::: warning
-Don't forget the `await` before `expect`. Vitest will detect unawaited assertions and print a warning at the end of the test, but it's best to always include `await` explicitly. Vitest will also wait for all pending promises in `Promise.all` before starting the next test, but relying on this behavior makes tests harder to understand.
-:::
-
-## Assertion Counting
-
-With async code, there's a subtle risk: an assertion inside a callback or `.then()` chain might never execute, and the test would still pass because no assertion failed. [`expect.hasAssertions()`](/api/expect#hasassertions) guards against this by verifying that at least one assertion ran during the test:
-
-```js
-test('callback is invoked', async () => {
-  expect.hasAssertions()
-
-  const data = await fetchData()
-  data.items.forEach((item) => {
-    expect(item.id).toBeDefined()
-  })
-  // if data.items is empty, the test fails instead of silently passing
-})
-```
-
-When you know exactly how many assertions should run, [`expect.assertions(n)`](/api/expect#assertions) is more precise:
-
-```js
-test('both callbacks are called', async () => {
-  expect.assertions(2)
-
-  await Promise.all([
-    fetchUser(1).then(user => expect(user.name).toBe('Alice')),
-    fetchUser(2).then(user => expect(user.name).toBe('Bob')),
-  ])
-})
-```
-
-In most cases, `async`/`await` with direct assertions is clear enough and you don't need assertion counting. It's most useful when assertions are inside callbacks, loops, or conditional branches where you want to guarantee they actually executed.
-
-::: tip
-If you want every test in your project to require at least one assertion, enable [`expect.requireAssertions`](/config/expect#expect-requireassertions) in your config instead of adding `expect.hasAssertions()` to each test manually.
-:::
-
-## Callbacks
-
-Some older APIs use callbacks instead of promises. Since Vitest works with promises, the simplest approach is to wrap the callback in a `Promise`:
-
-```js
-function fetchData(callback) {
-  setTimeout(() => callback('peanut butter'), 100)
-}
-
-test('the data is peanut butter', async () => {
-  const data = await new Promise((resolve) => {
-    fetchData(resolve)
-  })
-  expect(data).toBe('peanut butter')
-})
-```
-
-This pattern works for any callback-based API. Pass `resolve` as the success callback, and the test will wait until the callback is invoked.
-
-::: tip
-Most modern Node.js APIs (such as `fs/promises` and `fetch`) support promises natively, so you can use `async`/`await` directly. The callback wrapping pattern above is mainly useful for older libraries that haven't adopted promises yet.
-:::
-
-## Timeouts
-
-By default, each test has a 5-second timeout. If a test takes longer than that (perhaps because a promise never resolves, or a network request hangs), it will fail with a timeout error. This prevents your test suite from getting stuck indefinitely.
-
-You can set a [custom timeout](/api/test#timeout) as the third argument to `test`, which is useful for tests that legitimately need more time:
-
-```js
-test('long-running operation', async () => {
-  await someSlowOperation()
-}, 10_000) // 10 seconds
-```
-
-If you find yourself needing longer timeouts across many tests, you can change the default for all tests with the [`testTimeout`](/config/testtimeout) config option:
-
-```js [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    testTimeout: 10_000,
-  },
-})
-```
-
-## Unhandled Rejections
-
-By default, Vitest reports unhandled promise rejections as errors in the test run. If a promise rejects somewhere in your code and nothing catches it, the test run will fail, even if all your assertions passed. This is intentional: unhandled rejections usually indicate real bugs, like a forgotten `await` or a fire-and-forget promise that silently fails.
-
-```js
-test('this causes an unhandled rejection error', () => {
-  // This promise rejects but is never awaited or caught
-  Promise.reject(new Error('oops'))
-})
-```
-
-To fix this, make sure you `await` all promises or catch expected rejections:
-
-```js
-test('handle the rejection', async () => {
-  // Either await the promise
-  await expect(Promise.reject(new Error('oops'))).rejects.toThrow('oops')
-
-  // Or catch it explicitly if you don't need to assert on it
-  Promise.reject(new Error('expected')).catch(() => {})
-})
-```
-
-If your code intentionally produces unhandled rejections, you can filter specific errors with [`onUnhandledError`](/config/onunhandlederror) or disable the check entirely with [`dangerouslyIgnoreUnhandledErrors`](/config/dangerouslyignoreunhandlederrors).

package/vendor/vitest-docs/guide/learn/debugging-tests.md

@@ -1,210 +0,0 @@
-# Debugging Failing Tests
-
-This page covers how to investigate test failures in Vitest: reading error output, isolating problems, identifying common causes, and using the available debugging tools.
-
-## Reading the Error
-
-When a test fails, Vitest gives you several pieces of information. Let's look at a real failure and break it down:
-
-<<< ./snippets/debug-output-fail.ansi
-
-There's a lot here, but each part tells you something:
-
-**The header** (`FAIL src/user.test.js > createUser > sets the default role`) tells you which file, describe block, and test failed. This is the full path in the test tree.
-
-**The assertion message** (`expected { ... } to deeply equal { ... }`) tells you what kind of check failed and shows the two values being compared.
-
-**The diff** shows exactly what's different. Lines starting with <code class="diff-add">+</code> are what you actually got, and lines starting with <code class="diff-remove">-</code> are what you expected. In this case, the role was <code class="diff-add">"viewer"</code> but the test expected <code class="diff-remove">"member"</code>.
-
-**The code snippet** shows the exact line and a few surrounding lines, with a caret (`^`) pointing to the failing assertion. You can click the file path in most terminals and IDEs to jump directly there.
-
-At this point, the question is: did the code change (maybe the default role was intentionally updated to `"viewer"`), or is the test wrong? Check the source code for `createUser` to find out. If the default was intentionally changed, update the test. If not, you've found a bug.
-
-## Isolating the Problem
-
-When a test fails and the cause isn't immediately clear, the first step is to isolate it. Run just that one test, without the rest of your suite:
-
-```bash
-# Run only the failing test file
-vitest src/user.test.js
-
-# Run only tests matching a name pattern
-vitest -t "sets the default role"
-
-# Combine both for maximum precision
-vitest src/user.test.js -t "sets the default role"
-```
-
-You can also add [`.only`](/api/test#only) to the test itself:
-
-```js
-test.only('sets the default role', () => {
-  // only this test runs in the file
-})
-```
-
-If you have many failures and want to focus on the first one, use [`--bail`](/config/bail) to stop after a set number of failures:
-
-```bash
-vitest --bail 1
-```
-
-If the test passes when run alone but fails when run with others, you have a test isolation problem (more on that below). If it fails even when run alone, the issue is in the test itself or the code it's testing.
-
-## Common Causes of Failures
-
-### Shared State Between Tests
-
-This is one of the most common and frustrating issues. A test passes when you run it alone, but fails when the full suite runs. The usual cause is that some other test modifies shared state (a global variable, a module-level cache, a database) and doesn't clean up after itself.
-
-```js
-// This is a problem: `users` is shared between tests
-const users = []
-
-test('adds a user', () => {
-  users.push('Alice')
-  expect(users).toEqual(['Alice'])
-})
-
-test('starts empty', () => {
-  // This fails because 'Alice' is still in the array!
-  expect(users).toEqual([])
-})
-```
-
-The fix is to reset the state before each test with [`beforeEach`](/api/hooks#beforeeach), or better yet, use [`test.extend`](/guide/test-context#extend-test-context) to create fresh state for each test automatically:
-
-```js
-const test = baseTest.extend('users', () => [])
-
-test('adds a user', ({ users }) => {
-  users.push('Alice')
-  expect(users).toEqual(['Alice'])
-})
-
-test('starts empty', ({ users }) => {
-  // Passes: each test gets its own array
-  expect(users).toEqual([])
-})
-```
-
-### Async Issues
-
-Tests that involve promises can fail intermittently or in confusing ways if the async flow isn't handled correctly. The most common mistake is forgetting an `await`:
-
-```js
-// This test always passes, even if fetchUser rejects!
-test('fetches user', () => {
-  // Missing await: the test finishes before the promise settles
-  expect(fetchUser(1)).resolves.toMatchObject({ name: 'Alice' })
-})
-```
-
-Vitest will usually warn you about unawaited assertions at the end of the test. If you see that warning, add the missing `await`:
-
-```js
-test('fetches user', async () => {
-  await expect(fetchUser(1)).resolves.toMatchObject({ name: 'Alice' })
-})
-```
-
-If a test hangs and eventually times out, it usually means a promise never resolves. Check for missing callbacks, unresolved conditions, or deadlocks in the code you're testing.
-
-### Stale Snapshots
-
-If you're using [snapshot tests](/guide/learn/snapshots) and you intentionally changed the output of your code, the existing snapshots will be outdated. The test fails and shows a diff between the old snapshot and the new output.
-
-This is expected. Review the diff to confirm the changes are correct, then update the snapshots by pressing `u` in watch mode or running `vitest -u`.
-
-### Wrong Test Environment
-
-If your code accesses browser APIs like `document` or `window` and you see errors like "document is not defined", your test is running in the Node environment (the default). You can switch to a browser-like environment with the [`environment`](/config/environment) config option, or better yet, use [Browser Mode](/guide/browser/) which runs tests in a real browser.
-
-### Mocks Not Cleaned Up
-
-If a mock from one test leaks into another, you'll get unexpected behavior. For example, a `vi.spyOn` that overrides a method's return value will persist into the next test unless it's restored.
-
-The easiest fix is to enable automatic mock restoration in your config:
-
-```js [vitest.config.js]
-import { defineConfig } from 'vitest/config'
-
-export default defineConfig({
-  test: {
-    restoreMocks: true,
-  },
-})
-```
-
-This calls [`mockRestore()`](/api/mock#mockrestore) on every mock after each test. See the [Mock Functions](/guide/learn/mock-functions#resetting-mocks) tutorial for more details.
-
-## Debugging Tools
-
-### Console Logging
-
-There's nothing wrong with adding `console.log` to your tests. It's the fastest way to inspect values and understand what's happening:
-
-```js
-test('transforms data correctly', () => {
-  const input = getData()
-  console.log('input:', input)
-
-  const result = transform(input)
-  console.log('result:', result)
-
-  expect(result).toMatchObject({ status: 'ok' })
-})
-```
-
-Vitest displays console output inline with the test results, so you can see which test produced which log.
-
-### Vitest UI
-
-For a visual overview of your test suite, run Vitest with the `--ui` flag:
-
-```bash
-vitest --ui
-```
-
-This opens a browser-based dashboard where you can see all your tests, their status, and their output. It also includes a module graph that shows how your files are connected, which can help you understand why a change in one file causes failures in another. See the [Vitest UI](/guide/ui) guide for more details.
-
-### VS Code Extension
-
-The [Vitest VS Code extension](https://vitest.dev/vscode) lets you run and debug individual tests directly from your editor. You can click a "play" button next to any test, set breakpoints, and step through code in the VS Code debugger. This is often faster than switching between the terminal and your editor.
-
-### Verbose Output
-
-If the default output isn't showing enough detail, use the verbose reporter:
-
-```bash
-vitest --reporter=verbose
-```
-
-This shows every test individually (not just the files), which can help spot patterns in which tests pass and which fail.
-
-### Attaching a Debugger
-
-For more complex issues where you need to step through code line by line, you can run Vitest with the `--inspect-brk` flag and attach a debugger. The `--no-file-parallelism` flag ensures tests run in the main thread so breakpoints work reliably:
-
-```bash
-vitest --inspect-brk --no-file-parallelism
-```
-
-Then attach from VS Code, IntelliJ, or Chrome DevTools (`chrome://inspect`). See the [Debugging](/guide/debugging) guide for detailed setup instructions for each editor.
-
-## Getting Help
-
-If you're stuck, these resources can help:
-
-- The [Common Errors](/guide/common-errors) page covers specific error messages and their solutions
-- [GitHub Issues](https://github.com/vitest-dev/vitest/issues) for searching known bugs and workarounds
-- The [Discord community](https://chat.vitest.dev) for real-time help from other Vitest users and maintainers
-
-<style>
-.vp-doc code.diff-add {
-  color: var(--vp-c-green-2) !important;
-}
-.vp-doc code.diff-remove {
-  color: var(--vp-c-red-2) !important;
-}
-</style>