refactor: rename test/cli -> test/e2e, test/core -> test/unit (#10209)

Author: sheremet-va

.claude/agents/vitest-test-writer.md

@@ -1,6 +1,6 @@
 ---
 name: vitest-test-writer
-description: "Use this agent when the user needs to write comprehensive tests for Vitest features. This includes unit tests for individual functions, integration tests for CLI functionality, and browser mode tests. The agent should be invoked when implementing new features that require test coverage, fixing bugs that need regression tests, or expanding test coverage for existing functionality.\\n\\nExamples:\\n\\n<example>\\nContext: User has just implemented a new utility function in the codebase.\\nuser: \"I just added a new parseConfig function to the config package\"\\nassistant: \"I see you've added a new function. Let me use the vitest-test-writer agent to create comprehensive tests for it.\"\\n<commentary>\\nSince a new function was added, use the Task tool to launch the vitest-test-writer agent to write unit tests in test/core.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: User is working on a CLI feature.\\nuser: \"Please add a --json flag to the list command\"\\nassistant: \"I'll implement the --json flag for the list command.\"\\n<function call to implement the feature>\\nassistant: \"Now let me use the vitest-test-writer agent to write integration tests for this new CLI flag.\"\\n<commentary>\\nSince a CLI feature was implemented, use the Task tool to launch the vitest-test-writer agent to write integration tests in test/cli using runInlineTests.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: User wants to ensure a feature works in both normal and browser modes.\\nuser: \"Can you write tests for the new snapshot feature?\"\\nassistant: \"I'll use the vitest-test-writer agent to write comprehensive tests for the snapshot feature, covering both normal and browser modes.\"\\n<commentary>\\nSince the feature needs testing in multiple modes, use the Task tool to launch the vitest-test-writer agent to write tests in test/cli (for features supporting both modes).\\n</commentary>\\n</example>"
+description: "Use this agent when the user needs to write comprehensive tests for Vitest features. This includes unit tests for individual functions, integration tests for CLI functionality, and browser mode tests. The agent should be invoked when implementing new features that require test coverage, fixing bugs that need regression tests, or expanding test coverage for existing functionality.\\n\\nExamples:\\n\\n<example>\\nContext: User has just implemented a new utility function in the codebase.\\nuser: \"I just added a new parseConfig function to the config package\"\\nassistant: \"I see you've added a new function. Let me use the vitest-test-writer agent to create comprehensive tests for it.\"\\n<commentary>\\nSince a new function was added, use the Task tool to launch the vitest-test-writer agent to write unit tests in test/unit.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: User is working on a CLI feature.\\nuser: \"Please add a --json flag to the list command\"\\nassistant: \"I'll implement the --json flag for the list command.\"\\n<function call to implement the feature>\\nassistant: \"Now let me use the vitest-test-writer agent to write integration tests for this new CLI flag.\"\\n<commentary>\\nSince a CLI feature was implemented, use the Task tool to launch the vitest-test-writer agent to write integration tests in test/e2e using runInlineTests.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: User wants to ensure a feature works in both normal and browser modes.\\nuser: \"Can you write tests for the new snapshot feature?\"\\nassistant: \"I'll use the vitest-test-writer agent to write comprehensive tests for the snapshot feature, covering both normal and browser modes.\"\\n<commentary>\\nSince the feature needs testing in multiple modes, use the Task tool to launch the vitest-test-writer agent to write tests in test/e2e (for features supporting both modes).\\n</commentary>\\n</example>"
 model: opus
 color: green
 ---
@@ -13,9 +13,9 @@ You write comprehensive, high-quality tests that follow the established patterns
 
 ## Test Location Rules
 
-- **Unit tests**: Place in `test/core/`. These test individual functions by importing them directly, regardless of which package defines them.
-- **Integration tests**: Place in `test/cli/`. These test CLI functionality and features that require running Vitest as a process.
-- **Browser mode tests**: Place in `test/browser/`. However, if a feature supports both normal tests AND browser tests, place the tests in `test/cli/`.
+- **Unit tests**: Place in `test/unit/`. These test individual functions by importing them directly, regardless of which package defines them.
+- **Integration tests**: Place in `test/e2e/`. These test CLI functionality and features that require running Vitest as a process.
+- **Browser mode tests**: Place in `test/browser/`. However, if a feature supports both normal tests AND browser tests, place the tests in `test/e2e/`.
 
 ## Testing Patterns You Must Follow
 
@@ -51,15 +51,15 @@ To ensure all tests actually passed (not just that they ran), use `testTree` or
 
 ## Writing Unit Tests
 
-For unit tests in `test/core/`:
+For unit tests in `test/unit/`:
 1. Import the function directly from its source package
 2. Test pure functionality without process spawning
 3. Cover edge cases, error conditions, and typical usage
 4. Use descriptive test names that explain the scenario
 
 ## Writing Integration Tests
 
-For integration tests in `test/cli/`:
+For integration tests in `test/e2e/`:
 1. Use `runInlineTests` to define test scenarios
 2. Create realistic test file content
 3. Validate both stderr and the test results structure

.gitattributes

@@ -1,3 +1,3 @@
 * text=auto eol=lf
 
-test/cli/fixtures/reporters/indicator-position.test.js eol=crlf
+test/e2e/fixtures/reporters/indicator-position.test.js eol=crlf

.gitignore

@@ -23,16 +23,16 @@ bench/test/*/*/
 docs/public/user-avatars
 .eslintcache
 docs/.vitepress/cache/
-!test/cli/fixtures/dotted-files/**/.cache
+!test/e2e/fixtures/dotted-files/**/.cache
 test/**/__screenshots__/**/*
 test/**/__traces__/**/*
 test/browser/fixtures/update-snapshot/basic.test.ts
-test/cli/fixtures/browser-multiple/basic-*
+test/e2e/fixtures/browser-multiple/basic-*
 .vitest-reports
 *.tsbuildinfo
 # exclude static html reporter folder
 test/browser/html/
-test/core/html/
+test/unit/html/
 .vitest
 explainFiles.txt
 .vitest-dump

.vscode/tasks.json

@@ -58,7 +58,7 @@
       "label": "npm: test",
       "isBackground": true,
       "dependsOn": ["npm: dev"],
-      "detail": "vitest -r test/core --api",
+      "detail": "vitest -r test/unit --api",
       "problemMatcher": {
         "owner": "typescript",
         "fileLocation": "relative",

AGENTS.md

@@ -32,7 +32,7 @@ Vitest is a next-generation testing framework powered by Vite. This is a monorep
 - **All tests**: `CI=true pnpm test:ci`
 - **Examples**: `CI=true pnpm test:examples`
 - **Specific test suite**: `CI=true cd test/<test-folder> && pnpm test <test-file>`
-- **Core directory test**: `CI=true pnpm test <test-file>` (for `test/core`)
+- **Unit directory test**: `CI=true pnpm test <test-file>` (for `test/unit`)
 - **Browser tests**: `CI=true pnpm test:browser:playwright` or `CI=true pnpm test:browser:webdriverio`
 
 **IMPORTANT: Do NOT use `--` when passing test filters to pnpm.**
@@ -70,7 +70,7 @@ If you need to typecheck tests, run `pnpm typecheck` from the root of the worksp
 - `mocker` - Module mocking
 
 ### Test Organization (`test/`)
-- `test/core` - Core functionality tests
+- `test/unit` - Core functionality tests
 - `test/browser` - Browser-specific tests
 - Various test suites organized by feature
 

_typos.toml

@@ -2,7 +2,7 @@
 extend-exclude = [
   "*.js.map",
   "*.svg",
-  "test/cli/test/fixtures/reporters/html/**",
+  "test/e2e/test/fixtures/reporters/html/**",
 ]
 
 [default.extend-words]

eslint.config.js

@@ -14,17 +14,17 @@ export default antfu(
       '**/assets/**',
       '**/*.d.ts',
       '**/*.timestamp-*',
-      'test/core/src/self',
-      'test/core/test/mocking/already-hoisted.test.ts',
+      'test/unit/src/self',
+      'test/unit/test/mocking/already-hoisted.test.ts',
       'test/cache/cache/.vitest-base/results.json',
-      'test/core/src/wasm/wasm-bindgen-no-cyclic',
+      'test/unit/src/wasm/wasm-bindgen-no-cyclic',
       'test/workspaces/results.json',
       'test/workspaces-browser/results.json',
       'test/reporters/fixtures/with-syntax-error.test.js',
       'test/network-imports/public/slash@3.0.0.js',
       'test/coverage-test/src/transpiled.js',
       'test/coverage-test/src/original.ts',
-      'test/cli/deps/error/*',
+      'test/e2e/deps/error/*',
       'examples/**/mockServiceWorker.js',
       'examples/sveltekit/.svelte-kit',
       'packages/browser/**/esm-client-injector.js',
@@ -127,7 +127,7 @@ export default antfu(
     files: [
       `docs/${GLOB_SRC}`,
       `packages/web-worker/${GLOB_SRC}`,
-      `test/core/${GLOB_SRC}`,
+      `test/unit/${GLOB_SRC}`,
     ],
     rules: {
       'no-restricted-globals': 'off',

packages/runner/src/context.ts

@@ -50,7 +50,7 @@ export function withTimeout<T extends (...args: any[]) => any>(
 
   const { setTimeout, clearTimeout } = getSafeTimers()
 
-  // this function name is used to filter error in test/cli/test/fails.test.ts
+  // this function name is used to filter error in test/e2e/test/fails.test.ts
   return (function runWithTimeout(...args: T extends (...args: infer A) => any ? A : never) {
     const startTime = now()
     const runner = getRunner()

packages/ui/explorer.md

@@ -72,7 +72,7 @@ The new Explorer is using a flat structure to represent the tree via virtual scr
 It is using a new approach to handle the tree list, now we have a separated vue shallow ref for entries in the ui ([uiEntries in composables/explorer/state.ts](client/composables/explorer/state.ts)), and the WebSocket state using vue shallow ref for both, `idsMap` and `filesMap`, while keeping the state itself with Vue reactive.
 Now we are able to update the tree list only when the entries are updated and not when the WebSocket state is updated, which is a huge performance improvement.
 
-Some numbers running `test/core` with Vitest UI (162 files with 3 workspaces: 5100+ tests) in a `i7-12700H` laptop:
+Some numbers running `test/unit` with Vitest UI (162 files with 3 workspaces: 5100+ tests) in a `i7-12700H` laptop:
 - tree list: after server finishing running the tests, Vitest UI took ~1 minute to finish rendering the full tree (~150MB of memory usage)
 - explorer: Vitest UI finishing rendering the full tree before the server reporter shows the tests summary (~10MB of memory usage)